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 On Handling Exceptions in Delphi Exception Handling, using a tool like Delphi Crash / Exception Handling with Bug Reporting and some of the following related articles: