Re: Exception Handling
W dniu 2012-03-11 19:07, Lew pisze:
Novice wrote:
}
//ResourceBundle resourceFile = null;
try {
ResourceBundle resourceFile = ResourceBundle.getBundle(baseName,
locale);
return(resourceFile);
}
catch (MissingResourceException mrExcp) {
String msg = "Unable to find resources for base name, " + baseName + ",
and locale, " + locale + ". Check the spelling of the base name.";
throw new IllegalArgumentException(msg);
}
}
========================================================================
That works just fine and my exception, with stacktrace, is logged before
I've left getResources(). But why am I throwing the exception at the end
of the if (baseName == null) block? Why not just exit the program
gracefully instead of throwing the exception? If I pass it back up to the
Why, indeed?
caller, what is is actually supposed to do, given that the message has
been logged and recovery is not practical? Am I only passing it up so
that getLocalizedText() can stop the program?
No, only the operator should stop the program.
The idea is to return to valid program state. RETURN TO VALID PROGRAM
STATE.
*RETURN TO VALID PROGRAM STATE.*
Some errors are so bad, so only program termination is applicable. For
example when there is no valid state to recover.
Novice resource bundles it may be this case. If he have all GUI in XML
in bundles, or at least all language dependant data (GUI labels, menus,
etc), there is no valid state to recover. In this case program should
notify user (message box, with only OK button), and just die.
For console program, there is much more reasons to use exit(). Most
console programs just exit on error. Very few, usually complex ones,
try to recover.
Yet another case is server-side applet. In this case exiting on error is
standard strategy. Although in this case it exits through unhandled
exception, so server can handle termination reason.
--
Arivald