Throwing Exceptions Like Popeye


I was recently performing an ad hoc code review of a custom DLL when I saw what, in my opinion, was an over abundance of exceptions.  I went back to the developer and proceeded to discuss how we could refactor-away various exceptions, shorten certain Try/Catch blocks, possibly even mitigate them altogether, etc.

The developer, whom I consider to be a very smart and very patient man, listened earnestly and responded with what I felt was an excellent use of the Socratic Method:  “Hmm, but I thought that [in this one exception usage] we needed to let the caller know this particular item was incorrect.  Don’t we need to communicate something to them?”  (lots of paraphrasing)

“Communicate?”  Right away he had me seeing exceptions as part of the feedback loop, which I had forgotten in my zeal to optimize and refactor.  (We were in agreement on Try/Catch usage, by the way, which is generally to use sparingly with only the most critical lines of code.)

This started a great dialog between the two of us, and we eventually reached an alignment on exception usage in that instance.  I learned a lot from his viewpoint; and it also got me thinking more seriously about how exceptions are commonly used.

The Popeye Rule

I had typically written my own code with exception handling that followed what I loosely think of as “The Popeye Rule”:

That’s all I can stands and I can’t stands no more!

Meaning that I strived to write my code to be as robust as I could possibly make it, handling everything I thought a caller might possibly give me with guard clauses and graceful exits, finding every excuse I could think of to avoid Try/Catch blocks, etc.  I only wanted my code to ever throw an exception when something truly horrid and abnormal occurred and just couldn’t be handled any other way. 

(Super-extreme caveat: That does not mean I advocated, nor do I ever advocate, the intentional blind swallowing of exceptions.  I just didn’t like having code so brittle that it shattered into exceptions at the slightest fault).

“Let Me Tell You What Happened”

After talking with my colleague, I’m tending to not be so “ruggedly individualistic” with my views on how code should behave.  Instead of handling everything except for the very worst case/last-straw scenario and then throwing a spectacular, brawling exception (maybe tossing in some encoded GIFs of battleships firing their cannons into the stack trace), I want to give my caller information.  If something goes wrong, I need to let them know what happened and why.

I’ve done a lot of reading about how others feel about exception usage and so far the best overall guidelines I have found are Scott Hanselman’s here.  It’s a great short list that’s easy to follow.

Exceptions can seem like disruptions, even symptoms of brittle code or poor design; but this experience reminded me that their true purpose is to help by providing valuable feedback: “Something here went wrong.  Let me tell you what happened…[Stack Trace ensues]…”

Technorati Tags: ,,

%d bloggers like this: