ErrorHandler

The primary function of the Jet ErrorHandler is:

Catching and processing standard error messages.
Catching and processing uncaught exceptions.
Providing the handling of caught problems to custom handlers that the developer can add, modify and change in any way according to his needs. A handler is actually a module that does what you need to do with an error. This means that, for example, displaying errors is handled by a specific handler, logging is handled by another handler. The sample application includes handlers for error display, logging and displaying the error page "500" in case of a fatal error on the production environment.
The ErrorHandler also has support functions used by the Jet platform and applications built on it. For example, operator silence replacement in optional directories, last error information, and so on.

To understand the whole system, it is a good idea to study the following classes:

Class	Their meaning and purpose
Jet\Debug	A very basic class, also used by profiler. Its main purpose is to inform the debugging subsystem of the type of request that is currently being processed. More specifically, about the type of output that is expected (HTML, JSON, etc.).
Jet\Debug_ErrorHandler	Basic error handling class. Its main purpose is to keep a list of registered handlers, catch errors from PHP, and catch uncaught exceptions (and other things - see the class details). Thus, it is the class that is the centerpiece of the ErrorHandler subsystem.
Jet\Debug_ErrorHandler	Both errors and uncaught exceptions are always transformed by ErrorHandler into an instance of this class. It therefore represents the captured issue, which is passed to the individual handlers.
Jet\Debug_ErrorHandler	An abstract class from which children the individual handlers themselves.

Handlers and sample handlers (part of the sample application)

As mentioned above, handlers are modules that do what you need to do with the captured problem. That is, the form of the displayed error message is not handled by Jet, but by one of the handlers, as well as the form of logging and so on.

Handlers are part of the application space, you can find them in the directory ~/application/ErrorHandlers/

Feel free to look in the directory and edit everything as you need if you want. You can add your own handler as well. Just let it serve you the way you want :-)

Here's a list of the default handlers within the sample application

Handler	Handle Description
JetApplication\ErrorHandler_HTTPHeader	If this is a fatal error, then it will take care of sending HTTP return code 500.
JetApplication\ErrorHandler_Display	Ensures that the error message is displayed. Depending on the type of expected output (see class Jet\Debug ), it formats either text or HTML output and displays it. WARNING! This handler must not be active on a production environment. This is a security issue. However, you can script the initialization (see below) so that it is activated, for example, only for your IP (or by some other "magic") when you urgently solve some sudden problem. But you must always make sure that nobody but you can see the errors.
JetApplication\ErrorHandler_Log	Constructs a log entry and saves it (in a directory defined by Jet\SysConf_Path::getLogs() )
JetApplication\ErrorHandler_ErrorPage	Just as ErrorHandler_Display should be disabled on the production environment, this handler should be enabled instead. Its purpose is to, if possible, display something at least a little bit meaningful to the end user when the online application has already stopped working due to a serious error (just when it "crashed").

Handler Initialization

Initialization and setup is done in the script ~/application/Init/ErrorHandler.php .

In the default state, the initialization takes the following form:


use Jet\Debug_ErrorHandler;

use Jet\SysConf_Path;

use Jet\SysConf_Jet_Debug;



require SysConf_Path::getLibrary() . 'Jet/Debug.php';

require SysConf_Path::getLibrary() . 'Jet/Debug/ErrorHandler.php';



require SysConf_Path::getApplication() . 'ErrorHandlers/Log.php';

require SysConf_Path::getApplication() . 'ErrorHandlers/Display.php';

require SysConf_Path::getApplication() . 'ErrorHandlers/ErrorPage.php';





ErrorHandler_Log::register();



if( SysConf_Jet_Debug::getDevelMode() ) {

    ErrorHandler_Display::register();

} else {

    ErrorHandler_ErrorPage::register();

}



Debug_ErrorHandler::initialize();

Please note a few important things:

The Autoloader is not used, but the classic require. This is because the Autoloader is initialized after the ErrorHandler. Therefore, it is not possible (or even advisable) to use it.
Depending on whether or not the developer mode is active (see here), it activates just what is needed for the environment.

You can of course customize the initialization according to your needs.