Re: Java checked exceptions: how do i solve this?
ennioennioennio@gmail.com wrote,
How do i reflect these exceptions in the Node.getChildren() method?
Roedy Green wrote:
Probably the easiest way to handle this when you don't know what sort
of mess the implementor might throw is to make up a new Exception, and
have the implementor catch any miscellaneous exceptions and wrap them
in the new standard catch-all Exception and rethrow that.
Good advice, and to wrap them use the idiom that Ben Phillips explained:
Use solution 1 ...
throw new ChildrenLoadingException(detailMessage, originalException)
(punts to the Exception(String, Exception) constructor).
I repeat it because it's such good advice, and because it provides a detail
for the implementation of Roedy's advice. All the answers in this thread
coordinate with each other:
Joshua Cranmer:
think about the design of your code:
1. What does an SQLException or IOException mean in your case?
and
The notion of checked exceptions ...
... forces developers to actually properly handle errors
where they might blithely be ignored. In addition,
checked exceptions makes the documentation of errors a lot easier
The unifying notion is that checked exceptions are an API signature mechanism
to provide meaningful error recovery to client invocations.
The checked exception should have meaning appropriate to the component or
system layer that (re)throws it. For example, a Data Access Object
(DAO)-layer class likely would receive IOExceptions, particularly
SQLExceptions from the APIs it invokes. Those exceptions have meaning to it,
because a DAO "knows" about such things. What it throws is a "Data Access"
problem to upstream clients - perhaps derived from IOException but certainly
in its own, application-specific domain of discourse. Thus one would rethrow
new DataAccessException( "domain-meaningful message", ioExcFromDownstream )
as Ben showed.
Good encapsulation has the exception carry meaning in terms the invoker
understands, not what goes on under the API's covers.
--
Lew