Return to Revisions

Sometimes exceptions are fastest. I've seen cases where null object exceptions were faster even in Java than use of control structures (I cannot cite the study at the moment, so you'll have to trust me). The problem comes in when Java has to actually take the time and populate the stack trace of a custom exception class instead of using native ones (which seem to be at least partially cached). Before saying that something is unilaterally faster or slower, it would be good to benchmark.

In Python it is not only faster, but it is much more correct to do something which might cause an exception and then handle the error. Yes, you can enforce a type system, but that goes against the philosophy of the language -- instead you should simply try to call the method and catch the result! (Testing whether a file is writable is similar -- just try writing to it and catch the error).

I've seen times when it is faster to do something stupid like query tables which weren't there than to figure out whether a table exists in PHP+MySQL (the question where I benchmark this is actually my only accepted answer with negative votes).

All of that said, use of exceptions should be limited for several reasons:

1. Accidental swallowing of nested exceptions. This is major. If you catch some deeply nested exception which someone else is trying to handle, you have just shot your fellow programmer (maybe even you!) in the foot.
2. Tests become non-obvious. A block of code which has an exception in it could have one of several things wrong with it. A boolean, on the other hand, while theoretically it could be annoying to debug, it generally isn't. This is especially true as the try...catch control flow adherents generally (in my experience) do not follow the "minimize code in try block" philosophy.
3. It does not allow for an else if block. Enough said (and if someone counters with a "But they could use different exceptions classes", my response is "Go to your room and don't come out until you've thought about what you've said.")
4. It is grammatically misleading. Exception, to the rest of the world (as in not adherents to the try...catch control-flow philosophy), means that something has entered an unstable (though perhaps recoverable) state. Unstable states are BAD and it should keep us all up at night if we actually have avoidable exceptions (it actually creeps me out, no lies).
5. It is not compliant with common coding style. Our job, both with our code and with our UI's is to make the world as obvious as possible. try...catch control-flow goes against what are commonly considered best practices. This means it takes more time for someone new to a project to learn the project, which means an increase in the number of man-hours for absolutely no gain.
6. This often leads to code duplication. Finally blocks, though this is not strictly necessary, need to resolve all of the dangling pointers which were left open by the interrupted try block. So do try blocks. This means you can have a try{ obj.openSomething(); /*something which causes exception*/ obj.doStuff(); obj.closeSomething();}catch(Exception e){obj.closeSomething();}. In a more traditional, if...else scenario, the closeSomething() is less likely (again, personal experience) to be a copy and paste job. (Admittedly, this particular argument has more to do with people I have met than the actual philosophy itself).