One of the features of the Exception class is a new protected virtual function, declared as:
| procedure RaisingException(P: PExceptionRecord); virtual;
According to the documentation (that is, a comment in the source code, not the online help):
This virtual function will be called right before this exception is about to be raised. In the case of an external non-Delphi exception, this is called soon after the object is created since the "raise" condition is already in progress.
The implementation of the function in the Exception class manages the inner exception (by calling the internal SetlnnerException), which probably explains why it was introduced in the first place, at the same time as the inner exception mechanism.
In any case, now that we have this feature available we can take advantage of it. By overriding this method, in fact, we have a single post-creation function that is invariably called, regardless of the constructor used to create the exception. In other words, you can avoid defining a custom constructor for your exception class and let users call one of the many constructors of the base Exception class, and still have a custom behavior. As an example, you can log any exception of a given class (or subclass).
This is a custom exception class (defined again in the ExceptionsTest example) that overrides the RaisingException method: type
ECustomException = class (Exception) protected procedure RaisingException(
P: PExceptionRecord); override;
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.