You may be familiar with the term "fail fast" as it applies to software development. It basically states that errors should be reported sooner rather than later. So, for example, suppose an error occurs on line 30 (x has a null value when it shouldn't) but the error doesn't rear its head until line 246. This kind of thing can take hours to debug. A solution would be to place an assertion on line 31 like this:
if(x == null) throw new IllegalStateException("x should not be null");
A few corollaries to the fail-fast rule might be that compile errors are preferable to runtime errors. And errors caught in unit tests are better than errors caught in customer tests.
I would like to take the fail fast principal and expand it to "fail fast, fail nice" (FFFN). By nice, I mean this: the system has to give me a nice error message with enough information to quickly pinpoint and correct the problem. To me, FFFN is important. And not just in the code we write. But in the code we *use*: languages, libraries, frameworks, compilers, runtimes, IDE's, etc.
Let me give a few examples. A year or so ago, I decided to learn JavaFX. Being new, I made lots of mistakes. Every time I screwed up, JavaFX gave me the exact line number and column number of the error. And it gave a nice message telling me what i did wrong. In other words, right out of the gate, JavaFX seemed to succeed at FFFN. It was surprising to me because at this time JavaFX was brand new, not released yet, and mostly the brainchild of a single guy named Chris.
Consider JSF as another example. I had been using and teaching JSF for 3 years. In class, a student makes a mistake on his lab exercise. His app does not work. He just gets a blank screen. No stack trace. No error message. We turn up logging to its most verbose setting. Still nothing. In other words, the JSF implementation did not give us a *bad* error message. It gave us *no* error message. No clue. This kind of thing can takes hours to fix.
An other example would be GWT. If you make a mistake, GWT almost always tells you the exact line number with a friendly description. Compare this to JavaScript programming (without GWT). You often get the wrong line number. And a completely unhelpful error message (although Firebug can help a little).
Another example is Groovy. Every 6 months or so I get excited about Groovy. The clean, elegant syntax. Less need to repeat stuff (the DRY principal), closures, etc. I love Groovy. But then I loose my enthusiasm after a few mistakes take me into java stack trace hell. As of my last go around, Groovy scores high in most areas that are important to me. But it stills scores low in FFFN.
When developing with a low-FFFN tool (like JavaScript) you must drastically decrease your mean-time-between-testing.
What are your experiences? What technologies (languages, libraries, frameworks, compilers, runtimes, IDE's, etc) have you used that are particularly high-FFFN? Which tools have you used that are particularly low-FFFN? Is FFFN an important factor for you?
2 comments:
I agree totally, so we go back to Java and you have this crazy thing called a compiler tell you when you have done something wrong. ;)
I agree. I get very annoyed at exceptions that, for example, tell me a value is out of range, but don't tell me either the value or the valid range. The coder who wrote the exception has those value, so it doesn't take much work to pass them on. I always encourage my colleagues to provide useful information when throwing exceptions.
Post a Comment