Handling Exceptions in Delphi Exception Handling

What Happens When You Handle Exceptions

Web Programmer
Getty Images/ContentWorks

Here's an interesting fact: No code is error free -- In fact, some code is full of "errors" on purpose.

What's 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 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() here
end;

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;
except
  on EZeroDivide do
  begin
    //something when dividing by zero
  end;
  on EIntOverflow do
  begin
    //something when too large integer calculation
  end;
  else
  begin
    //something when other exception types are raised
  end;
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;
except
end;

Eating the exception means you don't know how to handle the exception or you don't 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;
except
  on E : Exception do
  begin
    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?

Here's 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 Delphi's 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.

More About Delphi Code