Handling Errors and Exceptions

Unfortunately, building applications includes coding. Regardless of how carefully you write/debug your program, it will be impossible to imagine every situation that can go wrong. Inexperienced user might, for example, try to open a nonexisting file or input a bad value into a data field.
Users make mistakes and we should be prepared to handle/prevent these errors wherever and whenever possible.

Errors, Exceptions?

An exception is generally an error condition or other event that interrupts normal flow of execution in an application. Whenever an error results from processing a line of code, Delphi creates (raises) an object descendent from TObject called the exception object.

Guarded Blocks

An application responds to an exception either by executing some termination code, handling the exception, or both. The way to enable error/exception trapping within a given code, the exception must occur within a guarded block of statements. The general code looks like:

try
   {guarded block of code}
except
   on <ESomeException> do begin
     {exception block-handles SomeException}
   end;
end;

A try / except statement executes the statements in the guarded block of code. If the statements execute without any exceptions being raised, the exception block is ignored, and control is passed to the statement following the end keyword.

Example:

...
Zero:=0;
try
  dummy:= 10 / Zero;
except
  on EZeroDivide do
    MessageDlg('Can not divide by zero!',
                mtError, [mbOK], 0) ;
end;
...

Protecting Resources

When a section of code acquires a resource, it is often necessary to ensure that the resource is released again (or you might get a memory leak), regardless of whether the code completes normally or is interrupted by an exception. In this case, the syntax uses finally keyword and looks like:

{some code to allocate resources}
try
   {guarded block of code}
finally
   {termination blok - code to free resources}
end;

Example:

...
AboutBox:=TAboutBox.Create(nil) ;
try
   AboutBox.ShowModal;
finally
   AboutBox.Release;
end;
...

Application.OnException

If your application doesn't handle the error that caused the exception, then Delphi will use its default exception handler - it will just pop up a message box. You may consider writing code in the OnException event for TApplication object, in order to trap errors at the application level.

Break On Exceptions

When building a program with exception handling, you may not want Delphi to break on Exceptions. This is a great feature if you want Delphi to show where an exception has occurred; however, it can be annoying when you test your own exception handling.

Few final words

The idea of this article is to give you just a quick look at what exceptions are. For further discussion on exception handling, consider some of the following related articles:

• Exceptional exceptions - learn about structured exceptions and some unusual ways to use them.
• Ignoring Exceptions with Delphi's Integrated Debugger - tired of always having Delphi integrated debugger load when an exception is raised? It doesn't have to be that way, and this article shows you how in Delphi 7, Delphi 8, and Kylix
• Exception Handling for Fun and Profit - exceptions are both powerful and very misunderstood. This talk will cover exceptions from top to bottom including their purpose, proper use, and the development of your own exceptions.