Jet\Debug_ErrorHandler_Handler
Every handler - module, i.e. a class that already does something with the error (display, log, send ...) must be a child of this abstract class.
You can read more about how to register a handler, for example, here.
But in essence it's simple. Here's a list of methods.
| Metoda | Význam |
|---|---|
| public static register( ): static |
Static method that registers the handler. |
| abstract public getName( ): string; |
The handler must be named something to identify it. Later it can be unregistered and the name is used for that. Abstract method - you have to implement it. |
| abstract public handle( Debug_ErrorHandler_Error $error ): void; |
And here it is happening :-) This method takes care of what happens to the captured problem. What exactly is up to you. Abstract method - you have to implement it. |
| abstract public errorDisplayed( ): bool; |
The handler must let the system know that it has somehow taken care of displaying the error (if it displays the error and it is not a handler intended for logging, for example). WARNING! At least one handler must be registered to handle the display (i.e. return true from this method). And this includes a handler like JetApplication\ErrorHandler_ErrorPage, which doesn't actually display the error, but only a placeholder page for the end user. Why does it so? There's nothing more annoying when "it" just doesn't work and doesn't show anything "it" does. It crashes and nothing ... That's why the system detects whether a serious error has been displayed in developer mode, and if not, it takes care of the temporary display of the error itself. I repeat that this is only for serious errors, when developer mode is enabled (SysConf_Jet_Debug) and only in a situation where no handler has been registered to display the error in the normal way. |