| The root of unchecked runtime exceptions thrown by the libraries. There is a
general movement to make most exceptions runtime exceptions,
since exception specifications often add verbosity without facility.
Checked exceptions are most appropriate for signalling problems between
libraries with a wide degree of separation. Within a single body of code,
unchecked exceptions should be used to propagate error conditions to the next
boundary.
Does Java need Checked Exceptions?
This class has a useful (and growing) body of schemes for absorbing the
target exceptions from other types of wrapping exceptions and rewrapping
them.
What we wish to preserve is a) the ultimate stack trace from the cause of the
problem and b) a set of increasingly detailed messages that can be accreted
onto the exception as it winds up the stack.
The typical usage in client code looks as follows:
<![CDATA[
try {
.... block generated checked or unchecked exceptions
}
catch (Exception e) {
throw UniversalRuntimeException.accumulate(e, "What I learned in this catch block" );
}
]]>
A UniversalRuntimeException also contains a Class representing its
"category", a point in the inheritance hierarchy that may be used to classify
the nature of exceptions, as being distinct from the wrapped target exception
intended to record its cause. An object of the category need not ever be
created, the inheritance hierachy may be queried via
Class.isAssignableFrom().
The exception category defaults to the concrete class of the exception being
wrapped.
author:
Bosmon | 