Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #12884

Re: Exception Handling

Show all headers | View raw

Patricia Shanahan <pats@acm.org> wrote in
news:zKidnZT6-s8LdsHSnZ2dnUVZ_sWdnZ2d@earthlink.com: 

> 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.
> 
That's where I went wrong. As I recall, I got into the habit of 
initializing every variable (with the odd exception) when I declare it 
simply to avoid compiler warnings about the value potentially being null  
later in the code. I didn't think it through very thoroughly and just 
started slavishly initializing everything upon being declared. It 
certainly worked for getting rid of compiler warnings but it wasn't 
nearly as smart as figuring out when it needed to happen and when it was 
ill-advised.

I'll need to start working on that....
> 
>>
>>
>>
>>>>     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?
> 
In short, if the baseName is null or misspelled, I can't think of a 
plausible recovery strategy so I'm (now) inclined to show the user a 
message that the program can't continue in a simple dialog with an Okay 
button; when he presses that, the program gets closed.

I'm still struggling a bit with the missing locale. I _could_ determine 
the default locale via Locale.getDefault() and it _might_ be different 
than the one determined in the program, Foo, in which case I _could_ go 
ahead and try to find the bundle for the default locale. But if it's a 
different language than the one the user wanted, I'm not sure I'm doing 
him a favor to show him a language he may not know. So I may treat the 
null locale scenario as being just an unrecoverable as the missing or 
incorrect baseName.

> 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.
>
Well, it's actually got three error cases: a null baseName, a null 
locale, and a baseName that doesn't have a corresponding file, which is 
caused by a spelling mistake in the base name. But I would certainly log 
a distinct message in any of those cases. 
>>
>> 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.
> 
I see what you're saying. In my particular situation, the missing 
resource bundle is a show-stopper but in other cases it might not be so 
it makes more sense to let getLocalizedText deal with that than to handle 
it in getResources(). And in some cases it might make sense to push it up 
even higher, even right up to main(). 

Okay, on the theory that some other program MAY be able to carry on even 
if the resources are missing - even though I can't think of a convincing 
case right this minute - I'll let getResources() log the problem and 
throw an exception, then let getLocalizedText() handle it. In my case, 
it's going to show a simple "Program ending" dialog with an okay button 
and pushing it is going to stop the program. That way, some future 
program that can carry on without the resources will be free to respond 
in some different way.

> 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. 
> 
And that brings up a minor point that I've wondered about for a while. Is 
there any standard approach to the integers that are used in System.exit
(). For instance, does a value of 16 typically indicate a severe error 
while a 4 indicates a minor error? (I'm thinking of the old IBM mainframe 
codes in my example.) It seems to me that the Java community may have 
some conventions in this regard that I should follow....


-- 
Novice

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Exception Handling Novice <novice@example..com> - 2012-03-11 01:51 +0000
  Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-10 18:39 -0800
    Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-11 11:53 -0300
      Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-11 10:51 -0700
        Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-11 16:35 -0300
    Re: Exception Handling Novice <novice@example..com> - 2012-03-11 17:05 +0000
      Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-11 10:53 -0700
        Re: Exception Handling Novice <novice@example..com> - 2012-03-11 20:36 +0000
      Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-11 11:07 -0700
        Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-11 17:00 -0300
          Re: Exception Handling Novice <novice@example..com> - 2012-03-11 22:02 +0000
        Re: Exception Handling Arivald <NOSPAMarivald@interia.pl> - 2012-03-11 21:03 +0100
          Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-11 18:31 -0300
        Re: Exception Handling Novice <novice@example..com> - 2012-03-11 21:54 +0000
          Re: Exception Handling Patricia Shanahan <pats@acm.org> - 2012-03-11 15:26 -0700
            Re: Exception Handling Novice <novice@example..com> - 2012-03-11 23:23 +0000
              Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-11 16:52 -0700
                Re: Exception Handling Novice <novice@example..com> - 2012-03-12 17:16 +0000
                Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-13 08:31 -0700
              Re: Exception Handling Patricia Shanahan <pats@acm.org> - 2012-03-11 17:51 -0700
                Re: Exception Handling Novice <novice@example..com> - 2012-03-12 17:26 +0000
            Re: Exception Handling Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 14:49 -0400
          Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-11 20:46 -0300
            Re: Exception Handling Novice <novice@example..com> - 2012-03-12 17:43 +0000
      Re: Exception Handling Patricia Shanahan <pats@acm.org> - 2012-03-11 11:14 -0700
        Re: Exception Handling Novice <novice@example..com> - 2012-03-11 22:35 +0000
          Re: Exception Handling Lew <noone@lewscanon.com> - 2012-03-11 16:58 -0700
            Re: Exception Handling Novice <novice@example..com> - 2012-03-12 15:44 +0000
              Re: Exception Handling Gene Wirchenko <genew@ocis.net> - 2012-03-12 10:34 -0700
      Re: Exception Handling Arivald <NOSPAMarivald@interia.pl> - 2012-03-11 20:34 +0100
        Re: Exception Handling Novice <novice@example..com> - 2012-03-11 22:36 +0000
    Re: Exception Handling Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 14:41 -0400
  Re: Exception Handling Arne Vajhøj <arne@vajhoej.dk> - 2012-03-12 14:37 -0400
    Re: Exception Handling Novice <novice@example..com> - 2012-03-12 22:43 +0000
      Re: Exception Handling Lew <lewbloch@gmail.com> - 2012-03-12 16:11 -0700
      Re: Exception Handling Arivald <NOSPAMarivald@interia.pl> - 2012-03-13 00:54 +0100
        Re: Exception Handling Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-13 06:05 -0300

csiph-web