A Word on Exceptions

11/15/2014

Exception handling is one of the basic things a programmer must know. Bad things happen during the execution of a program; a file cannot be accessed, a user enters a value that's out of bounds, the program runs out of memory, etc. Exception handling provides a means of responding to those "exceptional" conditions by switching the flow of execution of the program to a specialized block of code which contains instructions to respond to the occurrence of the exception. In addition to switching program flow, languages and execution environments that support exception handling typically provide an exception object that provides information on the exception that occurred and the state of the program when it occurred.

Over my years as a developer, I've learnt a thing or two concerning exception handling that I thought it would be useful to share.

One such lesson concerns when to throw an exception. I have seen exceptions thrown in situations where a variable is not set by a user or a SELECT database query returns no rows. I would argue that, in general, exceptions should only be thrown for faults that are either truly exceptional conditions or that are outside your control as a programmer. If a form requires certain fields to be filled by a user, don't let the user submit the form without filling the required fields. If the form fields specify certain data types, be sure to validate the input before processing. If a database call returns an empty result set, your program should in turn return an empty result object (not "null", if you can help it) to the caller. In general, exceptions should be thrown only when truly needed because it alters the caller's execution flow.

Another lesson is where to put your exception handling code (catch block). In general, you should not catch exceptions that they can't respond to or handle in some way. Instead, let the exception bubble up to the appropriate class or method that can handle it. Eventually, all exceptions that can be caught should be, unless you think having your application crash unexpectedly is a good idea. However, the catching class / method should be able to do something about the exception. There are a some situations where you may want to catch an exception, perform an action, such as perform some cleanup or do some logging, and then throw the exception up the chain. You should employ this strategy carefully though because in most languages you lose the stack trace that shows the actual origin of the exception i.e. the stack trace would show that the exception originated from your throw statement, instead of the original location.

When you do catch exceptions, you should always try to recover gracefully and logically. For example, if a database connection is unavailable, you may wait for a couple milliseconds and try again up to two additional times. When recovery is not possible though, the exception needs to be reported to the user with as much detail as the user needs to respond. An exception message that says "Could not open file because it was locked by another user" is better than an exception message that simply says "IO/file exception". For applications with human users, you need to know your users and tailor your error messages accordingly. Developer users are more savvy than business users and can handle more complex messages. Error messages targeted at business users or a general audience should use simple language to state what went wrong and what the user should do in response (e.g. try again in a couple of minutes, contact technical support, enter correct data, etc.). You can always provide a "More details" button with a stack trace or description of the machine / application state if needed, for debugging purposes.

Finally, for debugging purposes consider writing logs and giving users the ability to set the log level. This way, when an issue occurs, savvy users can increase the log level and send you the logs or do their own investigation. Also consider error reporting systems, like the one used by Firefox, that can either automatically or with the permission of the user send an error report back to you.

Thanks for reading!


You Might Also Like

0 comments