The Diaper Pattern Stinks
I mentioned the “Diaper Pattern” in a recent post and got some comments asking what the term meant. I had hoped to just link to an explanation, thinking it was a well-known antipattern, but several minutes of frustrated Googling have left me convinced that there’s actually a tiny knowledge gap to be filled here.
“Diaper Pattern” is a term that I picked up from working with Matt Wilson and David Stanek. It’s an anti-pattern about naively over-broad exception catching. A very basic example in Python might be:
try: do_something_that_might_throw_various_exceptions() except Exception: pass
If anything at all goes wrong in do_something, the except will catch and silence it–but we know that errors should never pass silently (unless explicitly silenced). It’s called a Diaper because it catches all the shit.
In practice, unless you have a good reason to catch everything, it’s a lot better to only catch the specific exceptions that need special handling, so that you’ll know right away about any runtime surprises and where they came from:
try: do_something_that_might_throw_various_exceptions() except IOError, e: # handle just IOErrors; let everything else make noise
Maybe it’s just a coincidence, but I’ve heard the term used more by developers who have young children than by those without kids.
Great post!
Yeah, any parent with a kid wearing diapers knows that you can’t trust your little angel’s smiling face to tell you if their diaper is clean. They might be grinning because they love how they just soiled themselves.
For highly available distributed systems I do like the diaper anti-pattern with the caveat that there is one top level diaper and only 1 diaper per major component (and when I say major I mean it. 2-5 in a complete system). The error is caught as a FATAL error and the levels above are told of the problem and to bring the system down cleanly, log it, and pass the task off to the next node to try again. The monitor watches to see if the problem occurs again on the next node (which means it is an endemic problem, not something which is based on system state or race conditions or hardware problems.)
The point is the anti-pattern only works if it is part of a much larger robust processing pattern, and should be used sparingly at known key points of integration. NOTE: for C++ the ‘catch (…)’ should not be used but instead a system for ‘catastrophic’ failure needs to be put in place, which should be able to handle a machine bursting into flame.
I think it deserves its Wikipedia entry:
http://en.wikipedia.org/wiki/Diaper_Pattern
Your original post about the diaper pattern[1] actually shows code that raises, not just passes (the joke is that it passes after it raises). Which sounds more like the “error hiding” anti-pattern: http://en.wikipedia.org/wiki/Error_hiding
The example code above subtly differs as all errors silently pass. But the program keeps running. I didn’t find any anti-pattern about that. I think this behavior fits the diaper pattern.
[1] http://www.pirnat.com/mike/2009/05/06/the-zen-of-doing-it-wrong/
@Alex Conrad
The worst part about letting the program keep running is that it has the expectation that everything in the try block executed without problems, which can lead to mysterious and difficult to debug problems elsewhere in the code. (Diaper leakage? You’re not sure where it came from, but it made a mess somewhere else. The metaphor gets a lot of mileage, I think… I like to refer to exception-raising errors in exception-handling code as “blowouts,” a term that I really wish I didn’t have practical experience with.)
I agree that the original example wasn’t quite as diaperish due to the immediate raise–and thank goodness it was just a plain raise instead of a “except Exception, e: raise e” that would have destroyed the original stack trace.
@Doug Napoleone
Yes, I think that’s the appropriate sort of place to Diaper, at those key integration points between systems. We’ve got some XML-RPC services in our backend and are happy to Diaper at the response level there so that we always guarantee a well-formed response (even one which signals an error). It’s a good tool in the right circumstance, but it has to be used wisely and sparingly, rather than casually and without regard for consequence.
ew, ur gross!
I don’t know why but that reminded me of my newbie days as a Java programer.