PermaLinkSome Lessons Learned From The 8.5.1 getDocumentByKey Regression
09:40:43 PM

As mentioned previously, the bug that Erik Brooks described here and here is not really limited to 8.5.1, and as Erik also pointed out, it is not just affecting getDocumentByKey, but listing all the releases and all the affected functions would make for an unwieldy article title, so I took a shortcut. Shortcuts are ok in blog titles. They're very often not ok, however, in code. So here are some lessons about shortcuts in code that my experience dealing with this bug has reminded me about.

Lesson 1: Exceptions that "can't happen" can happen How many times have you come to a place in your code and said to yourself, "if we made it to this point, the database is known to be good, the view is known to be good, the document is known to be good, the item is known to exist, so... nothing can go wrong". I've already actually blogged about a surprising case where this particular scenario can be false, but the getDocumentByKey regression bug is more of a classic case of a "can't happen" exception that really can happen. When the database is known to be good, and the view is known to be good, conventional wisdom holds that getDocumentsByKey won't throw an exception, yet now we know it can throw an error due to an 'invalid collection'

Corollary 1a: Paranoid error checking is good and Corollary 1b: Not checking for "can't happen" errors is a dangerous shortcut I'm reasonably happy with the level of paranoid error checking that I instinctively do in my production code, and the same is true for the members of my product team. I'm not perfectly paranoid, by any means, but in all of the cases in our product's code where the 8.5.1 getDocumentByKey regression might rear its head, there is in fact a try... catch block in close proximity to the lookup code.

Lesson 2: Every lookup operation can have three distinct outcomes The first outcome, and the one that we usually have foremost in our mind when we code a lookup, is success. Failure, though, is always an option. In fact, failure is two options. There is a difference between "lookup failure" and "failure to lookup". In many cases it is perfectly safe to treat these two cases the same way, typically because you're only ever doing lookups for documents that your application always expects to exist, so both failures are unexpected. In a context where you're doing a lookup for a document that might or might not exist, however, "lookup failure" and "failure to lookup" should be treated differently. For a lookup failure, you've proven that the document does not exist and you can take the action appropriate for your application -- possibly creating a new document. For a failure to lookup, on the other hand, you still don't know whether the document exists or does not, and at this point you're almost certainly better off aborting whatever you were trying to do.

Corollary 2a: Paranoid error checking needs to handle 'Failure To Lookup', not 'Lookup Failure' and Corollary 2b: catch(NotesException e) { result = null } may be a dangerous shortcut. In the Domino object model, lookup failure gives you a null result, and exceptions occur on failure to lookup. This is something that even seasoned Domino professionals may not recall off the top of their head, or they may be lulled into compacency by 15 years of never having actually seen a failure to lookup situation when the view is valid. If your application logic really should treat the two distinct failure cases the same way, then it's ok to put a try... catch around your lookup and have the catch block simply set the result to null, but using this as a pattern for all cases, however, is bad, bad, bad! That's reflexive "can't happen" thinking in action. You have to think about your application logic. If your application can't continue processing the current operation normally without definitively knowing whether the document you were looking for exists or not, then your catch block probably ought to throw an exception that will go up the chain, unwind (and recycle!) things properly, and then either abort the application altogether or move on to another operation that doesn't depend on knowledge about the particular document you had been looking for.

Lesson 3: Murphy's Law says that if you slip up on Lessons 1 and 2 just once in a huge code base, a Domino regression that turns a "can't happen" exception into a "does happen" exception will be disclosed a few weeks before you are scheduled to ship a major release of your code Sigh.

This page has been accessed 469 times. .
Comments :v

1. ninest12304/23/2016 04:46:46 AM

2. Coach Outlet03/14/2017 05:16:03 AM

kate spade handbags
coach factory outlet
Coach Outlet Store Online
Michael Kors Outlet
polo outlet
Polo Ralph Lauren Outlet Store
yeezy boost 350
Red Bottom Shoes
adidas nmd
Christian Louboutin Outlet
true religion outlet
true religion jeans outlet
Pandora Jewelry
Ferragamo Shoes
North Face Jackets
Polo Ralph Lauren Outlet
kate spade outlet
Ray Ban Sunglasses
Coach Outlet Store Online
Coach Factory Outlet Online
Coach Outlet Online
Coach Outlet
Michael Kor Factory Outlet
Michael Kors Outlet Online
Michael Kors Outlet
Michael Kors Factory Outlet Online
michael kors outlet
Coach Outlet Clearance
Michael Kors Online
Coach Outlet online
Michael Kors Outlet Online
nike shoes
nike outlet
cheap Jordan
retro jordan shoes
tory burch outlet
tory burch sale
oakley outlet online
cheap oakley sungalsses
ray ban outlet online
ray ban sunglasses outlet
coach outlet
the north face outlet
Michael Kors Bags
Coach Factory Outlet
north face jackets
Coach Outlet

Enter Comments^

Email addresses provided are not made available on this site.

You can use UUB Code in your posts.

[b]bold[/b]  [i]italic[/i]  [u]underline[/u]  [s]strikethrough[/s]

URL's will be automatically converted to Links

:-x :cry: :laugh: :-( :cool: :huh: :-) :angry: :-D ;-) :-p :grin: :rolleyes: :-\ :emb: :lips: :-o
bold italic underline Strikethrough

Remember me    

Monthly Archive
Responses Elsewhere

About The Schwartz


All opinions expressed here are my own, and do not represent positions of my employer.