6.1.1. Global Error Handler¶
Table of contents
This handler catches uncaught exceptions and errors that occur in the subsequent handler, performs log output and returns a result.
The process flow is as follows.
6.1.1.2. Module list¶
<dependency>
<groupId>com.nablarch.framework</groupId>
<artifactId>nablarch-fw</artifactId>
</dependency>
6.1.1.3. Constraints¶
- This handler should be placed at the beginning of the handler queue as far as possible
Since this handler processes exceptions, it should be placed at the start of the handler queue as far as possible, unless there is a particular reason.
If an exception has occurred in a handler that is placed before this handler, exception handling will be performed by the web application server or JVM.
If you want to output thread context information to the log when an exception is raised, put it after Thread Context Variable Delete Handler.
6.1.1.4. Process details according to the exceptions and errors¶
This handler generates the following process and results depending on the contents of the exceptions and errors that are caught.
- Process details according to the exception
Exception class Process details (Including subclass)
Calls ServiceError#writeLog and outputs log.
The log level differs depending on the implementation class of ServiceError.
After log output, returns ServiceError as the processing result of the handler.
(Including subclass)
Performs FATAL level log output.
After log output, returns Result.Error as the processing result of the handler.
Exception classes other than the above Performs FATAL level log output.
After log output, generates InternalError with the exception that is caught as the cause and returns it as the processing result of the handler.
- Process details according to the error
Error class Process details (Including subclass)
Performs INFO level log output.
After log output, the error that has been caught is rethrown.
(Including subclass)
Performs FATAL level log output.
After log output, generates InternalError with the error that has been caught as the cause and returns it as the processing result of the handler.
(Including subclass)
Performs FATAL level log output.
Since there is a possibility that FATAL level log output may fail (OutOfMemoryError may reoccur), the occurrence of OutOfMemoryError is output to the standard error output before the log output.
After log output, generates InternalError with the error that has been caught as the cause and returns it as the processing result of the handler.
(Including subclass)
Performs FATAL level log output.
After log output, the error that has been caught is rethrown.
Tip
Classes other than StackOverflowError and OutOfMemoryError are covered.
Error classes other than the above Performs FATAL level log output.
After log output, generates InternalError with the error that has been caught as the cause and returns it as the processing result of the handler.
6.1.1.5. If the global error handler cannot satisfy the requirements¶
The implementation cannot be switched by configuration for this handler. For this reason, a project-specific error processing handler has to be created if the requirements cannot be satisfied with this implementation.
For example, a new handler may be created instead of using this handler to switch the log level in detail.