Re: Exception Handling
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.
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.
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.
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.
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.
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.
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?
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.
What does your log look like with 'msg' printed twice?
}
//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.*
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?
[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?
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?
It all depends on the program, doesn't it?
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?
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.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg