Families. Can't live with them, can't legally kill them.
That's exactly how I feel about a lot of Exceptions; can't do anything about them, can't ignore them.
NamingExceptions, for example:
public static Connection getConnection(){
try {
Context context =(Context) new InitialContext().lookup("java:comp/env");
DataSource dataSource = (DataSource) context.lookup("jdbc/FooBar");
Connection connection = dataSource.getConnection();
return connection;
} catch (NamingException namingException) {
log.fatal(namingException);
throw new RuntimeException(namingException);
} catch (SQLException sqlException) {
log.fatal(sqlException);
throw new RuntimeException(sqlException);
}
}
If anything goes wrong here, then my whole application is probably hosed. So, I'm following the Bruce Eckel approach; don't throw errors if your client code has no hope of doing anything to recover. Is there anything more sensible that I can do?
Posted to Java by Simon Brunning at February 19, 2004 01:26 PMNope - thats how I handle it. User error (check exceptions only really) - catch and handle. Anything else (should only be unchecked exceptions), catch at the top level only, log and fail gracefully.
Posted by: Sam Newman on February 19, 2004 02:17 PMThis is the only thing you can reasonably do, and it's a damn shame that Java doesn't have a CheckedException class that is the root of all non runtime exceptions. It's a HUGE flaw, because all you ever want to do is
try
{
some code
}
catch (CheckedException ce)
{
log it
maybe rethrow it
}
but, instead you either end up checking Exception (which is just so wrong), or making a catch for each declared exception, only to do the same thing in each catch block.
Posted by: Dave on February 19, 2004 04:51 PMThe sensible thing would be to declare those exceptions on the method and handle them somewhere else. Somewhere where an intelligent decision can be made on how these exceptions can be handled.
By rethrowing them as Runtime you're making the decision for the calling code - that it is fatal and that it must die. That's a pretty restrictive contract and not very robust. You don't know that it's completely fatal for the calling code - necessarily.
Posted by: Foo on February 19, 2004 09:19 PMThis approach tends to result in cleaner logs and better reporting: http://weblogs.java.net/pub/wlg/987
Posted by: Bob Lee on February 19, 2004 09:53 PMFoo, I think that you are missing my point. I specifically excluded the idea having this method throw the exceptions because I don't *want* to handle them somewhere else. Nothing can be done about them, and requiring every plane in my code which needs a connection to handle NamingExceptions is *exactly* what I'm seeking to avoid.
Bob, That's pretty much exactly what I am doing.
Posted by: Simon Brunning on February 20, 2004 09:08 AMThe idiom you have described is the one I use too. In my experience, exception-handling is the most common source of ghastly Java code. I have seen systems of which the source code is 80% devoted to exception-handling, usually because system exceptions have been allowed to propagate up to places that have no context for handling them usefully. You might also consider the LoggableException idiom described in http://www-106.ibm.com/developerworks/library/j-ejbexcept.html.
Posted by: David Pinn on February 23, 2004 05:05 AM52dPfk hi! mi site is http://norffg.com
see you!
formal evening wear dresses, maternity evening dresses formal gowns
Posted by: evening prom dresses on June 22, 2011 12:49 PM