Re: Exception Handling
Lew <noone@lewscanon.com> wrote in news:jjipli$np7$1@news.albasani.net:
Novice wrote:
Lew wrote:
Novice wrote:
snip
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?
I'm not sure if I should be returning anything at all. Maybe I should
just log and stop the program?
I said *if* that's the strategy. What do you think? It may depend on
the specifics of the case.
The bundle being sought is for use on the GUI. Displaying the GUI without
text is useless.
The nature of the error is a factor. If I'm passing a null for the
baseName, the program couldn't reasonably work out an alternate resource
bundle to use, nor could the user of the program. In that case, the
program should end with a SEVERE error written to the logs. If I'm
passing in a null locale, getResources() could determine the default
locale and use it, probably advising the user that it had done so and
logging that it had made this substitution. If the baseName were present
but misspelled, I don't see how the program could proceed.
So, in short, I could probably cope with a null locale but not a null or
misspelled baseName.
However, if the logic that I messed up in getLocalizedText() was supposed
to yield a language other than the one returned by Locale.getDefault()
(my proposed recovery strategy if locale is null in getResources(), the
GUI would display a different language than the user wanted. That might
be just as bad as a GUI without text if the user was, say, Japanese and
didn't know English, assuming English was the default locale.
Fair enough. I've converted each constants interface to a class with
a private constructor that throws an exception if someone tries to
instantiate it.
How would that exception ever occur? How could "someone" ever try to
call a private constructor?
Don't throw code into a program that is provably never called.
Tip 6 in the article makes the point that it is redundant and
expensive
We've discussed this before, remember?
It's not expensive. When you're calling a logger statement for an
error, the cost of the error SWAMPS the time in the logger. Think
about it.
I suppose I'm too easily swayed by other opinions. Arved, who seems very
knowledgeable, cited that article, which seemed to give it his seal of
approval. I don't know the author of the article but I tend to assume he
must be an expert to be asked to write about a Java topic. The author
cites people who he considers experts and the upshot is that the advice
seems to argue against putting positioning information in the log unless
its necessary (which it probably isn't if the stacktrace is in the log).
Now you make a persuasive argument contradicting the article. I'm
satisfied that you have serious expertise in this area so I have no
reason to dismiss your argument. But why didn't the experts who wrote the
article modify their remarks accordingly?
I am more than happy to include class name, method name and line number
in a log record. Those three things and the message text are the most
useful parts of the log record to me. They give me enough information
that I can find the right spot in the code and start to set up test
conditions to try to duplicate the error and find out what is causing it.
The stacktrace gives me that key information too but one of the questions
I haven't asked yet is whether I should always put a stacktrace in the
log for every problem situation. I'm inclined to think I should do so for
errors that get logged as SEVERE but not for FINE/FINER/FINEST messages.
WARNING and INFO messages are iffier and probably have to be decided on a
case-by-case basis. If I'm not writing a stacktrace, then I'll want the
log record to include the message, class name, method name and line
number at the very least and very likely things like the thread if I'm
doing multiple threads.
to get class, method and line information if it is already in the log
message. A stacktrace will tell me all of that and more so shouldn't
I be concentrating on getting a stacktrace, plus whatever I'll need
that isn't in the stacktrace, like the date and time of the problem?
There are many who have answered this question, in response to your
questions.
The answers covered a lot of approaches. Perhaps you recall them.
I've had a lot of suggestions over the last few days and, in all honesty,
they are starting to blur in my mind.... Obviously, I need to reread some
of those threads....
Now, finally, here are some questions:
Since the only exceptions I anticipate, MissingResourceException
and NullPointerException, are unchecked exceptions, I gather than I
shouldn't really do anything about them aside from logging when
they happen. Okay,
I disagree. You should end the program gracefully and get someone to
fix the programming error right away.
But what's the right way to end the program? System.exit()? That
seems
Under operator control.
the obvious way but as I've said further down, that doesn't seem to
be the method used in the books and articles I've been reading.
What's the better way?
Under operator control.
fair enough; I certainly don't want to display the source code to
my user, make them enter the correct value for the baseName, make
them recompile the program and then run it again! But when/where
should I log the error? For instance, if I mess up my coding
somehow and inadvertently
In the log file.
Yes, I realize that it goes in the log file. I mean when and where in
my code do I do that? In getResource() or getLocalizedText()?
Wherever you detect the error.
Good. That makes perfect sense to me.
pass a null in the baseName, should getResources() be testing its
input parameters individually to see if they are null and write a
message to the log if they are null from within that method? I'm
inclined to say yes
Always check all parameters for validity, either by an explicit
check for a public or protected method, or by controlling what's
passed to package-private or private methods.
A normal practice is to have an application-specific checked
exception to throw, or to throw the standard unchecked exception.
For example:
if (argument == null)
{
final String msg = "null argument";
IllegalArgumentException except = new
IllegalArgumentException(msg); logger.error(msg, except);
throw except;
}
or similarly for application checked exception 'FooException'.
throw new FooException(new IllegalArgumentException(msg));
At least one of the articles/books recommended against creating
custom exceptions unless necessary, preferring to use existing
exceptions where possible.
The Java Tutorial puts it this way:
"You should write your own exception classes if you answer yes to any
of the following questions; otherwise, you can probably use someone
else's.
- Do you need an exception type that isn't represented by those in
the Java platform?
- Would it help users if they could differentiate your exceptions
from those thrown by classes written by other vendors?
- Does your code throw more than one related exception?
- If you use someone else's exceptions, will users have access to
those exceptions? A similar question is, should your package be
independent and self-contained?"
I don't _think_ I qualify to create my own exception under any of
these conditions so I'm inclined to stay with the standard ones. Or
am I missing something?
Yes.
It is common and frequently useful to create an application-specific
checked exception. Again, and I've said this many times, think about
what will be useful when troubleshooting a problem. Many times, a
custom exception is useful. It says that the underlying exception has
been caught, logged and wrapped.
But how is a custom FooException better than a good ol'
IllegalArgumentException? I'm not quite getting that yet.
Please understand that I have no objection to creating my own exceptions.
I've actually done it in the past and didn't find it difficult.
Runtime exceptions are dangerous because they slip past you. If you
catch them in a custom checked exception then code must handle it. All
those runtime exceptions are related, by dint of being exceptions
within the same application. BOOM! Qualified.
It sounds a little bit like you're saying that RuntimeExceptions should
be made into chccked exceptions when possible. But I doubt you mean that.
That seems to contradict what Stelting at least is saying and even the
API. The spirit of the API seems to be that some things don't lend
themselves to easy recovery and you shouldn't even try, ergo the
existence of unchecked exceptions and errors. Naturally, some things DO
lend themselves to easy recovery by the user so it makes perfect sense
that if a given file isn't found, the user can be given a chance to
select a different file with a file chooser, which explains why
FileNotFoundException is a checked exception.
Assuming I'm not, I'm inclined to use the first approach you
suggested. Or perhaps use the technique but throw a
NullPointerException. Bloch implied that IllegalArgumentException was
fine for bad values but that NullPointerException was preferred where
a parameter had a null value.
That's his opinion.
Many others think that 'IllegalArgumentException' makes more sense if
it's an argument that has an illegal value.
What do you think?
Like I said, I'm fine with either approach. They're both unchecked
exceptions and you'd handle them the same way. It feels like a matter of
personal style to me, meaning I'm free to do what I like on my own code
and I should follow the shop standard if I'm working for someone else.
Somewhere up the stack you should catch the exception and convert it
to valid program state"
catch(RuntimeException except)
{
forwardProgramControlToErrorScreen();
}
I went into Eclipse for a minute and amended getResources() to look
like this:
======================================================================
== static public ResourceBundle getResources(String baseName, Locale
locale) throws NullPointerException, IllegalArgumentException {
if (baseName == null) {
final String msg = "The base name cannot be null.";
NullPointerException nullPointerException = new
NullPointerException
(msg);
Logger logger = Logger.getLogger(CLASS_NAME);
logger.log(Level.SEVERE, msg, nullPointerException);
throw nullPointerException;
}
if (locale == null) {
final String msg = "The locale cannot be null."; //$NON-NLS-1$
NullPointerException nullPointerException = new
NullPointerException
(msg);
Logger logger = Logger.getLogger(CLASS_NAME);
logger.log(Level.SEVERE, msg, nullPointerException);
throw nullPointerException;
Kind of a bad name for the variable, there.
You mean nullPointerException? I've gotten into the habit of giving my
instance names the same name as the class (except for the case of the
first letter) so I'm used to doing things that way. It seems clearer
since it avoids any possibly misunderstanding that this isn't just an
exception but is an instance of NullPointerException.
What does your log look like with 'msg' printed twice?
A bit redundant given that the same message appears at the top of the
stacktrace. But just having "SEVERE" without any other message seems like
a bad idea. What do you think I should have if in the log record (the
part that isn't the stacktrace) if not 'msg'?
}
//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.
I think I need to be clear about who the operator is. In the case of a
game, say, we're talking about the person playing the game (assuming a
game that has only one player, like a solitaire game). Same kind of
reasoning for a utility like a program that burns CDs or whatnot. For a
servlet that is running in a container like Tomcat and may have hundreds
or thousands of instances running, we'd have both individual users of
individual copies of the program as well as some kind of admininstrator
managing the container. Have I got that about right?
If so, I'm not clear which operator you mean in the case of a servelet.
Assuming only one instance of an application was having trouble, I'd
expect the user to be the operator in question. In a case where all
instances of an application were having problems, I'd expect the
administrator of the container to shut down all instance of the problem
program pending a resolution.
If that's all more-or-less right so far, then what is the operator
experience going to be when the program has to deal with a null baseName
and the program is a game or utility? It would seem reasonable to display
a dialog with a "Sorry, we hit a snag and can't proceed" kind of message
that includes an okay button. It could go further and advise the user to
contact Tech Support and even display messages and diagnostics but I
expect most of that would be over the heads of users and should be
reserved for the logs. Then, when they press Okay, the program ends.
Is that about what you had in mind?
The idea is to return to valid program state. RETURN TO VALID PROGRAM
STATE.
*RETURN TO VALID PROGRAM STATE.*
I hear you; I'm just not sure what a valid program state would be in my
case. Honestly, I'm not entirely sure what "valid program state" implies
in ANY case ;-)
to that but I'm not sure what to do next. It seems pointless to
carry on with getResources() since
ResourceBundle.getBundle(baseName, locale) will fail on a
NullPointerException with a null in either parameter. I could throw
a NullPointerException so that getLocalizedText() can deal with it.
But how do I get a stacktrace into the log if I follow that
strategy? It's easy enough to get the stacktrace once I've caught
an exception but I'm just talking about recognizing that an input
parameter is null; there's no exception at that point to put in my
log.
There is if you create one. That's why Java has the 'new' operator.
Yes, I see that from your technique of creating one. I hadn't
anticipated that approach.
That's why Java has the 'new' operator.
If I let getResources() throw NullPointerException if either
parameter is
Better, use 'IllegalArgumentException'.
null, then I can let getLocalizedText() catch those
NullPointerExceptions and get the stacktraces from the exception
and write them to the log. In that case, I may as well just check
the input parameters for nulls, and simply throw
NullPointerException with a specific message within
'IllegalArgumentException'.
I have no strong feelings about this one way or the other but Bloch,
on page 248 of Effective Java (2nd edition) says: "Arguably, all
erroneous method invocations boil down to an illegal argument or an
illegal state, but other exceptions are standardly used for certain
kinds of illegal arguments and states. If a caller passes null in
some parameter for which null values are prohibited, convention
dictates that NullPointerException be thrown rather than
IllegalArgumentException."
Can we agree that whether I use IllegalArgumentException or
NullPointerException in the situation I'm describing in my own code
is simply a matter of personal style or preference? Or is there a
reason to prefer IllegalArgumentException that Bloch failed to
consider?
What do you think?
I'm easy with either approach. It feels like a personal style thing to
me. The main thing is that the problem is detected and logged with enough
information that the operators and/or programmers can figure out what
went wrong. At the end of the day, the specific exception thrown doesn't
seem particularly important.
[snip]
One other questions. When, if ever, should I execute System.exit()
with a non-zero integer? In my example, I know that program Foo
can't proceed
Never. Program exit should be under user control.
So, given that my application has a GUI, leave the application
suspended at the exception and make the user click the Close button?
Why is that better than just exiting given that the program can't
proceed without the missing resources in this case?
That depends. What constitutes valid program state? Should you just
stop, leaving the user wondering WTF happened? Should you perhaps come
to a screen that tells the user something went wrong, and give them
some choices?
Aside from not being clear about the meaning of "program state", I see
your point.
How do you feel when a program suddenly ends? What if you could've
supplied the missing "e" in the file name without having to start
everything all over again?
Absolutely. I think it would be dandy to enlist the user's assistance in
getting back out of trouble rather than crash the program on him.
It all depends on the program, doesn't it?
Yes.
Programs should really only end under operator control. But hey, do it
your way. What makes sense? What irritates the user? What's even
possible?
Fair enough. I'm all in favor of the user having a positive experience
rather than have them scratching their heads and muttering WTF!
In short, you've won me over. I think displaying a dialog and explaining
that we have to end is more than reasonable and is better than just
closing it on the user's behalf without any clear communication. My only
quibble is that the dialog is a bit of an empty gesture in the sense that
the user doesn't REALLY have much in the way of control when he gets a
dialog with only an Okay button on it. The program is already dead in the
water and his only option is to press Okay to officially kill the
program. That's not really "control" in a very strong sense. But I agree
that it is strongly preferable to do that than to just close it without
telling him what's going on in some way.
If this were a batch program rather than one with a GUI, would we
close with System.exit()? Or wait for the operator to notice the
program is suspended and make him kill it?
You tell me. The questions too vague. Describe the scenario precisely,
with the advantages and disadvantages of each approach. With more
information about your particular case, maybe I can advise.
I didn't really have a specific scenario in mind when I said that. It
just struck me that the answer would probably be different in a situation
like that than the case of a standalone utility or game. As you say, a
good programmer would consider that in devising his strategy for handling
the problem.
--
Novice