12th Chapter-Exception Handling and program debugging (i) (1)

How to detect and handle the running errors of programs in application development is a very important issue. The Delphi integrated Development Environment (IDE) provides a complete built-in debugger that can help you find most bugs. But not all errors can be found, and when the program involves data exchange with peripherals or operating peripherals, such as requiring user input, read and write disk, and so on, the error occurs is not controlled by the program, such as the importation of illegal characters, disk can not read and write. These situations not only cause the application to abort abnormally, but can cause the system to crash. To solve these problems, Delphi also provides a set of powerful exception handling mechanism. Using it cleverly can make your program more robust and more user-friendly.

Although Delphi provides an application with a default set of automatic exception handling mechanisms, the current module exits the current module and gives an error message, without immediately causing the application to abort. However, when application execution is highly procedural, it is not enough to take advantage of this method, and it can easily lead to unpredictable execution of programs.

12.1 Delphi Exception handling mechanism and anomaly class

The Delphi exception handling mechanism is based on the concept of Protection block (Protected Blocks). The protection block is a piece of code that is encapsulated with a reserved word try and end. The protection block is created to automatically create an appropriate exception class (Exception) when an application error occurs. The program can capture and handle this exception class to ensure that the program ends properly and that the resource is freed and data is not corrupted. If the program does not process, a message box is automatically provided.

Exception class is the core of Delphi exception handling mechanism, and it is also the main feature of Delphi exception handling. The following is a detailed introduction to the concepts and systems of exception classes.

All exception classes provided by Delphi are subclasses of class exception. Users can also derive a custom exception class from exception.

The exception class is defined as follows, and is not listed for infrequently used members.

{sysutils cell}

Exception = Class (TObject)

Private

fmessage:pstring;

Fhelpcontext:longint;

function getmessage:string;

Procedure Setmessage (const value:string);

Public

Constructor Create (const msg:string);

Constructor createfmt (const msg:string; const Args:array of const);

destructor Destroy; Override

Property Helpcontext:longint

Property message:string;

Property messageptr:pstring;

End

The most important parameter in a series of exception constructors is the error message that is displayed. The most important of the data members is the message string (MESSAGE,MESSAGEPTR) that can be referenced. This information is important for customizing an exception class and handling an exception class, respectively.

Delphi provides a very large exception class system, which involves almost every aspect of programming. From the big aspect we can divide the exception class into the Run-time library exception, the object exception, the part exception three kinds. Below we introduce separately.

12.1.1 Run-time Library Exception class (RTL Exception)

Run-time library exceptions can be grouped into seven classes, all defined in Sysutils library units.

12.1.1.1 I/O exceptions

The I/O Exception class Einouterror is the result of an attempt to operate on a file or peripheral in a program run, and it derives from exception by adding a public data member errorcode to save the code for the error that occurred. This member can be used to take a different approach to different situations after an I/O exception occurs.

When the compile instruction {$I-} is set, the I/O exception class is not generated and the error code is returned to the predefined variable ioresult.

12.1.1.2 Heap exception

Heap exceptions are generated in dynamic memory allocations, including two classes of Eoutofmemory and Einvalidpointer.

Table 12.1 Class of heap anomaly and its cause

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Exception class causes

─────────────────────────────────

Eoutofmemory does not have enough space to meet the required memory allocations

Einvalidpointer illegal pointer. It's usually caused by a program trying to release a pointer that has been released.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━