Exceptions

Exceptions follow a subclassing hierarchy in Guildhall. The base class is TGuildhallException. If this is thrown Guildhall will quit, announcing the module and line number to the user on a final screen.

TAppletException subclasses from TGuildhallException. When this is thrown, the applet has failed and must be cleaned up. This level needs to be further developed before being really useful (August 2021).

TException subclasses from TAppletException. This error is recoverable if the applet is set up to handle such things. The console applet Terminus does a pretty good job with this. It can catch a number of errors and print the error message to the console without failing.

Subclasses of TException are used to identify certain kinds of problems and allow the applet to discern among them. A couple of examples would be TStreamException and its subclass TFileException. These are very handy when an applet's coding understands that these exceptions can be thrown. The applet can then respond accordingly, for example by asking the user to confirm when a file is about to be overwritten after an exception was thrown when writing the file was attempted.

Guildhall will also catch and rethrow any exception not in its hierarchy, the purpose of catching it being to aid debugging.

Guildhall offers several routines to assist in checking errors. The two most common ones are AssertOrFail and AssertOrThrow. Each one tests a boolean and if the test does not pass an exception is thrown. The file name and the line number of the assertion are provided in the exception. AssertOrFail throws a TGuildhallException and AssertOrThrow throws a TException. These same exceptions can be generated easily without the boolean test when logic so dictates, the former with the NotImplemented inline and the latter with IllegalOperation inline.

Constructible Classes