I
- the type of the input exceptions.O
- the type of the output exceptions.@NotThreadSafe public interface ExceptionHandler<I extends Throwable,O extends Throwable>
Optionally, the implementation may perform additional operations such as logging the input exception or storing it for later use. This implies that the implementation may be stateful and mutable, which in turn implies that the cooperative algorithm should not bypass this interface, i.e. it should never simply create and throw an exception without calling this exception handler. Otherwise some information, such as previous cause exceptions for example, could get lost.
In general, the type parameter for the input exception is determined by the cooperative algorithm, whereas the type parameter for the output exception is determined by the client application. Where possible, the cooperative algorithm should declare generic method signatures in order to enable the client application to select the type of the thrown exception as desired (see below).
As an example for a cooperative algorithm which may benefit from using this interface, consider the recursive copying of a directory tree: Among many others, the copy algorithm may encounter the following exceptional conditions:
Now the implementation may decide whether the copy algorithm shall proceed with the remaining files and directories in the tree or if not, if the cause exception should get wrapped in another exception in order to enable diagnosing the situation by its client application.
The copy algorithm could use two different exception handlers: One for any exception when reading from a source file and another one for any exception when writing to a destination file. If these exception handlers would map any cause to a different exception type, then this would enable the client application to analyze the situation and take appropriate action.
However, if the client application doesn't care, it could simply provide the same exception handler for both input and output exceptions to the copy algorithm.
Here's how a generic method declaration for a copy algorithm could look like:
public <I extends Exception, O extends Exception>
copy( File src, ExceptionHandler<IOException, I> inputHandler,
File dst, ExceptionHandler<IOException, O> outputHandler)
throws I, O {
// ...
}
Note that the first type parameter for both handlers is an
IOException
for the input exceptions whereas the the second
type parameter determines the type of the output exceptions which may get
thrown by the exception handlers themselves.
Modifier and Type | Method and Description |
---|---|
O |
fail(I input)
Called to handle an exception which doesn't allow the caller
to proceed with its task.
|
void |
warn(I input)
Called to handle an exception which may allow the caller to
proceed with its task.
|
O fail(I input)
input
- the input exception to handle.void warn(I input) throws O extends Throwable
O
.
If the implementation maintains a state, it must get updated
so that this instance can get reused to handle more exceptions.Copyright © 2012–2014 Schlichtherle IT Services. All rights reserved.