The Relevance blog has an excellent post on simplifying code called Refactoring from Ceremony to Essence. In part it explains why people find Ruby on Rails to be a compelling alternative to J2EE, but it also illustrates a number of techniques applied by Ruby on Rails that could just as easily be used regardless of which language you’re using to develop your applications.
One point in their post directly addresses the “use less indentation” rule I posted about on Sunday. I spoke in favor of doing all of the basic sanity checks up front in a method and avoiding nesting, this post recommends leaving them out entirely:
Conditionals make code expensive to test; so ceremonial conditionals are a particular nuisance. Let framework error handling deal with missing data on the form.
I need to give that one a little more thought.
May 13, 2008 at 10:33 am
It looks like you may have accidentally linked to yourself with the first link?
http://blog.thinkrelevance.com/2008/4/23/refactoring-from-ceremony-to-essence
May 13, 2008 at 10:51 am
Indeed. That’s fixed now.
May 13, 2008 at 2:49 pm
The alternative is to have framework error handling take the actual errors produced by library code and know how to interpret and display them. That’s the approach we have. Do it once and do the deepest job of validation you can do. If synchronous UI validation is required, drive it from metadata that the library makes available, rather than separate config files.
Exceptions do not in themselves work well for this approach, because they imply a single failure. With web operations that are frequently “batched” in the sense that validation does not or cannot happen except for when an entire form is submitted, you may have many errors. So you need a framework for collecting errors and supplying them to the UI in a list rather than a single failure. We have an exception that collects other exceptions and have our library calls declared to throw that; then the specific exceptions are documented too so they can be used in front-end code. The messages are given in a field-keyed, I18N-friendly format – (fieldId, “file.not.found”, filename, directory) – rather than plain precomposed strings.
The expectation should be that things you call may throw either a single exception, or a collection of exceptions. If you don’t know how to handle them, you let them flow past you (our exceptions are almost all unchecked). If you have more to add yourself, you make a new collection and add the previous stuff and your stuff to it. If you made a library call, expect that exceptional conditions may produce a list of failures and be ready to handle them.
The languages and libraries ought to be smart enough to encourage this kind of pattern of use. They’re not, and there doesn’t seem much of a standard for it, unfortunately.