Re: Exception Handling
On 3/11/2012 10:05 AM, Novice wrote:
Lew<noone@lewscanon.com> wrote in news:jjh39f$crc$1@news.albasani.net:
Novice wrote:
snip
I have a utility class called LocalizationUtils which basically
houses convenience methods dealing with i18n/l10n. One of its methods
is getResources(). It expects two parameters, a String representing
the "base name" (the leading part of the resource file name) and a
locale.
Here's the code for getResources() with all comments and error
handling (aside from the empty catch block) stripped out:
====================================================================
static public ResourceBundle getResources(String baseName, Locale
locale {
ResourceBundle locList = null;
Don't use throwaway initializations, usually.
Why?
If I omit that line and simply use the following in the try block:
ResourceBundle locList = ResourceBundle.getBundle(baseName, locale);
locList isn't visible after the try/catch so that I can return it.
There are two issues, where to declare the variable and whether to
initialize it. The visibility issue means you have to declare it outside
the try/catch.
The issue is whether to initialize it in the declaration. If you do
that, you throw away some compile time checking. Does every path leading
to the return assign an appropriate value to locList?
There are a few situations in which a human programmer can tell that all
necessary assignments are being done, but the compiler cannot. In those
cases you may need to initialize in the declaration, but that is not the
way to start.
Even if I wanted to return null if you go through the catch block, I
would explicitly assign null in the catch block. Doing so shows future
readers, myself included, that I thought about the issue and meant it to
be null if the exception happened.
try {
locList = ResourceBundle.getBundle(baseName, locale);
}
catch (MissingResourceException mrExcp) {
Log and return 'null' if that's the recovery strategy for this
exception.
Is that what I should do, return null if there is a problem getting the
resource?
How do you intend this method to be used? What does its Javdoc comment
say about missing resource bundles?
I generally prefer throwing exceptions to returning null in this sort of
situation. The reasoning is that the caller may want to take different
actions for different failures. Returning null, even after logging the
details, deprives the caller of any way of distinguishing different
cases. I realize this particular method currently only has one error
case, but that may change later.
I'm not sure if I should be returning anything at all. Maybe I should
just log and stop the program?
Direct exit from a low level method is rarely a good idea. It limits its
usefulness. Generally, you should pass the buck up the stack, for
example by throwing an exception or returning null.
If you do that, your method can be used in contexts in which the missing
resource bundle is not fatal. Maybe the call arguments were derived from
GUI input. In that case, the user should be told about the problem and
invited to change the input. Maybe one transaction depends on the
resource bundle, and that transaction needs to be aborted, but the
program can keep on going.
Even in a batch program, you may be part way through processing some
input, and it is possible to do more validation, and find more input
errors, in a single run.
Or maybe there is a sensible default, and your caller knows what it is.
If you throw an exception or return a result that specifically indicates
missing resource bundle, the caller can use the default.
If you throw an exception, and this really is a situation in which the
correct action is to terminate the program, the exception will filter up
the stack to a level that knows, for example, that it is the main method
in a batch program. It can call System.exit with the appropriate error code.
Patricia