On Handling Exceptions in Delphi Exception Handling

Heres an interesting fact: No code is error free — in fact, some code is full of errors on purpose. Whats an error in an application? An error is an incorrectly coded solution to a problem. Such are logic errors that could lead to wrong function results where everything seems nicely put together but the result of the application is completely unusable. With logic errors, an  application might or might not stop working. Exceptions can include errors in your code where you try to divide numbers with zero, or you try using freed memory blocks  or try providing wrong parameters to a function. However, an exception in an application is not always an error. Exceptions and the Exception Class Exceptions are special conditions that require special handling. When an error-type condition occurs the program raises an exception. You (as the application writer) will handle exceptions to make your application more error-prone and to respond to the exceptional condition. In most cases, you will find yourself being the application writer and also the library writer. So you would need to know how to raise exceptions (from your library) and how to handle them (from your application). The article on handling errors and exceptions provides some basic guidelines on how to guard against errors using try/except/end and try/finally/end protected blocks to respond to or handle exceptional conditions. A simple try/except guarding blocks looks like: try ThisFunctionMightRaiseAnException();except//handle any exceptions raised in ThisFunctionMightRaiseAnException() hereend; The ThisFunctionMightRaiseAnException might have, in its implementation, a line of code like raise Exception.Create(special condition!); The Exception is a special class (one of a few without a T in front of the name) defined in sysutils.pas unit. The SysUtils unit defines several special purpose Exception descendants (and thus creates a hierarchy of exception classes) like ERangeError, EDivByZero, EIntOverflow, etc. In most cases, the exceptions that you would handle in the protected try/except block would not be of the Exception (base) class but of some special Exception descendant class defined in either the VCL or in the library you are using. Handling Exceptions Using Try/Except To catch and handle an exception type you would construct a on type_of_exception do exception handler. The on exception do looks pretty much like the classic case statement: try ThisFunctionMightRaiseAnException;excepton EZeroDivide dobegin//something when dividing by zeroend; on EIntOverflow dobegin//something when too large integer calculationend; elsebegin//something when other exception types are raisedend;end; Note that the else part would grab all (other) exceptions, including those you know nothing about. In general, your code should handle only exceptions you actually know how to handle and expect to be thrown. Also, you should never eat an exception: try ThisFunctionMightRaiseAnException;exceptend; Eating the exception means you dont know how to handle the exception or you dont want users to see the exception or anything in between. When you handle the exception and you need more data from it (after all it is an instance of a class) rather only the type of the exception you can do: try ThisFunctionMightRaiseAnException;excepton E : Exception dobegin ShowMessage(E.Message); end;end; The E in E:Exception is a temporary exception variable of type specified after the column character (in the above example the base Exception class). Using E you can read (or write) values to the exception object, like get or set the Message property. Who Frees The Exception? Have you noticed how exceptions are actually instances of a class descending from Exception? The raise keyword throws an exception class instance. What you create (the exception instance is an object), you also need to free. If you (as a library writer) create an instance, will the application user free it? Heres the Delphi magic: Handling an exception automatically destroys the exception object. This means that when you write the code in the except/end block, it will release the exception memory. So what happens if ThisFunctionMightRaiseAnException actually raises an exception and you are not handling it (this is not the same as eating it)? What About When Number/0 Is Not Handled? When an unhandled exception is thrown in your code, Delphi again magically handles your exception by displaying the error dialog to the user. In most cases, this dialog will not provide enough data for the user (and finally you) to understand the cause of the exception. This is controlled by Delphis top level message loop where all exceptions are being processed by the global Application object and its HandleException method. To handle exceptions globally, and show your own more-user-friendly dialog, you can write code for the TApplicationEvents.OnException event handler. Note that the global Application object is defined in the Forms unit. The TApplicationEvents is a component you can use to intercept the events of the global Application object.