First, don't catch Exception
. Catch a specific subclass.
Second, yes it may be that an underlying IOException
, which is what this looks like, should be wrapped in an app-specific exception. You could have, for instance:
final class DBGlobalsException extends Exception
{
Field somethingDBGlobalsSpecific;
//where this is shorthand for chained constructors that look like Exception
DBGlobalsException(String message, Throwable cause)
{
super(message,cause);
}
// elaborate your exception with whatever error state you want to propagate outwards
void setField(Field ...) {}
}
And you could then
catch (IOException ex) {
DBGlobals.Error("OHMjson.Graph.saveLastGraphName - Error: " + ex.getMessage());
msg = "Unable to save data";
status = false;
DBGlobalsException dbe = new DBGlobalsException(msg,ex);
dbe.setField(status /* or whatever */);
throw dbe;
}
See also: Throwing Exception
, Throwing new and old exceptions, Rolling your own. That's just a few, there are a bunch of great SO Q+A's on exception handling, chaining, etc. Some useful best-practices stuff outlined at WikiBooks.
Also read Oded's answer and think it through... your exception should encapsulate whatever status (error codes, flags, etc...) are required for the outer code to recover from the condition -- or it should be an unrecoverable condition (see RuntimeException
).
Finally, the canonical Effective Java reference: Item 43: Throw Exceptions Appropriate to the Abstraction.