As a side note, we are not interested in the try finally end block in this chapter. The finally processing block does not require the use of any additional code, classes, and all that is needed to use it is in the System.pas system module (included in the way used by each module in a way transparent to the programmer). There are no restrictions in KOL to use it. It will be about blocks of the try except end type, and in particular about the ability to recognize what kind of exception occurred by analyzing the code of the raised exception.
In the Delphi VCL, exception handling requires working with classes because all exception objects inherit from the Exception class, which is a direct inheritor of the TObject base class. Classes are not used in the KOL library. The very fact of adding classes does not increase the application by much (about 2.5K), but the exceptions are described in the SysUtils module, the connection of which already adds more than 20K to the weight of the finished program. Therefore, in order to enable KOL programs to handle exceptions without inflating their size too much, I added the err.pas module at the time.
This module contains a KOL-specific definition of the Exception class. Moreover, unlike the Delphi standard, you do not need to use inheritance to use it. The rule here is "do not inherit unless strictly necessary." In accordance with the same rule, KOL organizes graphic tools for drawing a canvas (brush, pencil, font - in one object type), basic visual objects (TControl). As already mentioned, creating a new inheritor will add at least one more virtual method table (vmt) to the application's weight, 4 bytes for each virtual method that exists in the class and all its ancestors in the inheritance hierarchy.
That is, in order to raise its own exceptions in the KOL application, there is no need to inherit its class from Exception. It is enough to write:
raise Exception.Create (e_Custom, 'some error message here');
This option is useful if you just need to distinguish your software exceptions from standard system exceptions, which include, for example, division by zero (e_ZeroDivide).
If your exceptions also need to be classified by type, then the following exception constructor will do:
raise Exception.CreateCustom (my_code, 'some error message');
When constructing an object of type Exception, the number my_code is assigned to the ErrorCode property, and then can be parsed in the exception handling block as usual. For example:
try
... code that can lead to an exception
except on E: Exception do
if E.ErrorCode = my_code then…
end;
Of course, when there are many such codes, it may be more convenient to use the multiple choice construct case (which, by the way, is impossible to distinguish between the exception classes in the VCL, inherited for each of its kind of exceptions).
The err module is in the https://www.artwerp.be/kol/kol-mck-master_3.23.zip archive, along with the kolmath and Cplxmath modules discussed below.
