This article also appears in Canadian Developer Connection.
The trouble with a lot of example code covering exceptions is that the examples are often cases in which you shouldn’t be using an exception in the first place. Consider the classic known as “Someone’s trying to divide by zero” – here’s the C# version:
// C#
try
{
result = dividend / divisor;
}
catch (DivideByZeroException ex)
{
Console.WriteLine("Idiot.");
}
and here’s the Ruby version:
// Ruby (works in IronRuby too!)
begin
result = dividend / divisor
rescue ZeroDivisionError
puts "Idiot."
end
// You have to hand it to Ruby for picking great keywords for
// exception handling. While C# borrowed Java's "try / catch / finally",
// Ruby went with the more macho "begin / rescue / ensure".
// As Yoda himself would say: "Do or do not. There is no try."
The better approach would be to do a little defensive programming and make sure that divisor is non-zero before performing the division operation. So why do tutorials on exception handling almost always bring out the “Someone’s trying to divide by zero” example?
There are two reasons:
- It’s simple. It’s only a handful of lines of code.
- It’s predictable. Set the value of divisor to zero and the exception gets thrown. Always.
The truly exceptional exceptions — I/O errors, timeouts and other things that cause exceptions are a little harder to set up and take more code to handle. Hence the divide-by-zero example; it illustrates try and catch (or rescue in a Ruby block) in a way even the newest newbie can understand.
The problem is that many tutorial authors don’t get any deeper than simply explaining the keywords with simple examples, leading people to misuse exceptions, either as a substitute for checking for preconditions or as an unstructured form of flow control in the style of the much-maligned goto (which in many cases is considered harmful).
Like goto, exceptions are unstructured jumps, which make your program’s flow more complex. Unlike goto, exceptions are computationally “expensive” because of all the extra work involved in setting up and backtracking program flow that comes with a thrown exception.
A good guideline to follow is that exceptions are for exceptional cases. Stuff that you can’t easily predict. You can tell if a division operation is going to result in an undefined result – just look at the divisor! Harder to predict are things like whether a server access will time out or if the hard drive will decide that the moment you’re reading a file is the best possible time to corrupt it. Those hard-to-foresee, believed-to-be-rare, exceptional cases are really what exceptions are meant to handle.
Think of exceptions is as being like the airbags in your car. The idea is that they’re a last resort; they’re no substitute for defensive driving. (Like airbags, they’re also expensive to reset.)
Lee Dumond goes into further detail on the topic of defensive programming as being like defensive driving in an article titled Defensive Programming, or Why Exception Handling Is Like Car Insurance. He cites the “Someone’s trying to divide by zero” example, provides a list of defensive programming strategies that you should consider before coding up that exception handler and talks about those exceptional cases when you will have to use an exception. Check it out!
Over at Canadian Developer Connection, the blog I’m actually paid to write for, I’m asking readers – presumably Canadian software developers who write code for Microsoft’s platforms – if they write code in Visual Basic. I’ve posted code in C# and (Iron)Ruby, plan to post code in (Iron)Python, F# and JavaScript, but none in Visual Basic.
