Re: Exceptions
nukleus wrote:
To summarize: the custom exceptions are used to bring up
some fine graining into error handling structure. Instead of
using the standard exceptions, such as IOException, socket,
or Exception itself, we use those custom exceptions
and catch them in various places above to precisely affect
the recovery code. In the main routines, various exceptions
are caught starting from the mist fine grained level, and
going down to the Exception level, if we did not catch
the any lower level custom exceptions.
I will not treat your points in detail here, but instead speak to the
strategies for using exceptions.
Generally, what you describe is viable, perhaps not best practice but not so
terrible on the face of it. The danger, almost a certainty in the real world,
especially given your descriptions in other threads of the coding style that
you inherited, is that the implementation of the strategy is flawed in the
details.
Here are Lew's Laws for the use of exceptions (not guaranteed to be clever or
correct, but presented as a starting point). This post runs a little lengthy.
1.
Exceptions, as the name implies, are for exceptional circumstances. Use
regular logic for things you expect.
instead of
public void act( Entity entity )
{
try
{
System.out.println( entity.name );
}
catch ( NullPointerException e )
{
System.out.println( "null entity" );
}
}
use
public void act( Entity entity )
{
if ( entity == null )
{
System.out.println( "null entity" );
}
else
{
System.out.println( entity.name );
}
}
2.
Return codes are better than throws, when either the result makes sense within
the problem domain or a reasonable default exists.
public boolean storeData( Entity entity )
{
// Set up a PreparedStatement with an INSERT ...
try
{
ps.execute();
}
catch ( SQLException se )
{
logger.error( e );
return false; // clearly the exception means that the store failed
}
finally
{
ps.close();
}
// more logic and cleanup ...
return true;
}
3.
Log your exceptions.
Corollaries: Have a logging strategy. Include in it a standard logging format.
4.
Do something with received exceptions at the first point of reception.
Even if an exception will be rethrown, you should at least log it at the point
of first capture. You will have available the fullest possible context at that
moment. Then either rethrow, convert to a custom or convert to a
problem-domain value.
5.
An application should define a custom exception, possibly two, the first
extending Exception and the other RuntimeException.
You probably do not need any more than these two. Use constructors that take
the causal exception as a parameter. (Roll your own in J 1.3, use the
corresponding super() calls in J 1.4+.) Your custom exceptions should expose
all four constructors.
6.
Analyze each potential exception situation individually. Does it make sense to
"eat the exception" and convert to a default value or action? Should you throw
an exception? Should it be a standard exception or a custom one? (I typically
throw standard Java RuntimeExceptions like IllegalArgumentException, but use a
custom checked exception.)
7.
Exceptions are essentially value objects. They shouldn't log, and they damn
sure shouldn't do anything within the problem domain. (By which I mean that an
Exception should sport no methods that do these things.)
To apply these "laws" to your problem, I'd say to make sure that the code logs
exceptions at first contact, that throws occur only when necessary, not for
"in the domain" occurrences, and that the recovery actions make sense.
- Lew