… Or what every developer should know about the implementation of exception handling (in your compiler/os):
Modern Exception Handling (EH) in C++, JAVA, Ruby, Modular-3, C# and other modern programming languages is a great tool for handling errors but unfortunately it is sometimes abused by software developers that do not quite get what exceptions are really for or are just ignorant of possible implementations.
The handling of exceptions must be done at runtime by your compiler/os/virtual machine, since it is generally not possible to predict in advance which handler to transfer control to, identify which exception has been raised, where to perform object cleanup during the propagation of an exception and how much memory to pre-allocate for exception storage. Sometimes the EH runtime mechanism is compiler-specific and a part of compiler’s runtime library. In other cases, support for EH is provided through the operating system or virtual machine.
Common abuses of EH that affect performance include using exceptions as an alternative flow control mechanism (think sophisticated “goto’s” and you got the basic idea of this antipattern”)……. Don’t do that. It will only make the code harder to read. It will also make your code slower to execute since throwing exceptions are generally very expensive operations.
Another less apparent misuse of EH is usage of try-catch(-finally), or similar constructions your language may offer, inside the control flow of hotspots (such as inside time critical loops). Don’t do that, as a the try-catch-finally construction may have overhead even when you won’t expect it.
So why are throwing exceptions expensive and why may the try-catch-finally constructions (or similar) have overhead ? Well, it all depends on the language, the implementation of your VM or compiler (and sometimes on whether you use native code or not if your language allows it). Depending on your environment, just raising one exception can be from 10-100.000 times as slow as alternatively returning a simple return code from the method (in particular depending on if a dynamic registration approach or a static table approach is used to support control flow transfer). And even if you don’t raise any exception, just having a try-catch-finally in your control flow can also be moderately expensive (but usually only enough to be a real problem inside hotspots).
Specifically, the case of overhead of try-catch-finally constructions when no exceptions occur is difficult to get rid of by compiler & virtual-machine implementers. Few implementations on selected virtual machine and chip architecture got it right and have 100% overhead-free implementations but many impose a overhead just for placing try/catch/finally constructions in your control flow. Basically this is because something like a “linked list” may have to be maintained internally by the compiler or VM each time the control flow enters or exits a try-catch-finally (unless you are luck to run om a fully static table driven implementation of EH).
For much more details about various possible implementations of exception handling and the impact on performance refer to this old thesis of mine here (not up-to-date for virtual machines though).
In conclusion, the morale of the story is:
* Do use exception handling for error handling only (not for control flow).
* Don’t use try-catch-finally constructs inside hot-spots (i.e. loops and such) if it can be avoided. Do the try-catch at a higher level that is called less often.
* If your particular java, c++, ruby, clr … implementation of exception handling on one chip architecture yields excellent performance even when you break the above rules you are just plain lucky. Change the version, vendor or chip architecture and you luck may desert you. Therefore don’t do it 
P.S. This post is not about good use EH in general…. But of cause, don’t forget to use exception handling when it is necessary and in particular do NOT ignore exceptions. I have also seen quite a few mistakes in code where exceptions are catched and then ignored. I have even seen senior developers do this in difficult places like event-handlers where one have to go the extra mile to actually handle the error (one way to do this is to create have the main thread manage errors and transfer exceptions to that thread in the event handlers ; but that is long story so I will reserve that for another blog posting)
Notice:
This post is slightly updated version of a posting originally from my old blog at “http://www.mortench.net/blog” which I will shortly retire for good.
mmc
41 technologies 