Not Every Exception is a Bug
Exceptions can represent failures outside of a program's control
Issue: 11.3 (May/June 2013)
Author: Seth Verrinder
Author Bio: Seth is a consultant who uses Real Studio every day in his job at BKeeney Software, Inc.
Article Description: No description available.
Article Length (in bytes): 5,694
Starting Page Number: 72
Article Number: 11309
Related Web Link(s):
Excerpt of article text...
It's easy to think of exceptions as bugs and often that is the case. A NilObjectException is one example of an exception that always indicates a bug because it means that a variable wasn't initialized or some code used a function that might return Nil but didn't check the result (watch out for SQLSelect). But what about an IOException? If you try to write to a file and the disk fails causing an IOException that's not a bug in
yourprogram, it's a bug in the external world where your disk lives.
Separating Bugs from Failures
In my infinite spare time, one of the things I like to do is try out other programming languages. There are always valuable ideas that may be common in one language community but not so well known in others.
Recently I've begun playing with Clojure, a modern variant of Lisp. Rich Hickey, the creator of Clojure, gave a talk titled
The Language of the System(see http://www.youtube.com/watch?v=ROor6_NGIWU). It's mostly about distributed systems and it's partly a lament that the tools we have inside our programs are much better than the tools we have to make programs talk to each other. But one statement he made stood out to me: he said "distributed error modes are the only error modes". What he meant was that the services a program depends on may not be available and that those dependencies represent ways that a system can fail that you need to deal with not as bugs but as failures that are outside your program's control. They are the real errors.
I think a similar distinction applies to exceptions in Real Studio. When you think about the types of exceptions that might occur and how to handle them, think about whether they represent a failure of something your program depends on (like a disk, network connection, or database).
Dealing with Failure
...End of Excerpt. Please purchase the magazine to read the full article.