Re: When to throw exceptions and when to use System.err?
Eric wrote:
Lew wrote:
One way to ignore runtime exceptions is to completely ignore them and allow
them free rein to crash your app:
public void foo( String sometxt )
{
System.out.println( "Input length "+ sometxt.length()
+" value\n\""+ sometxt +'"';
}
Oops. This just lets the runtime exception percolate up out of the method to
damage the caller.
What runtime exception? You didn't catch or throw any exceptions
NullPointerException. And failure to catch or prevent the exception is
exactly the mistake illustrated, so that was intentional.
there. Eclipse doesn't have any warnings or errors on that block,
other than the syntax error for the missing ).
Oops. Thanks for pointing out the parenthesis mistake.
Did you know that Eclipse's warnings are configurable? Turn on the null
pointer warnings.
Eric wrote:
Is a try block necessary to catch an exception or only if failure is
an option?
Lew wrote:
I don't understand the question.
A 'catch' block is necessary to catch an exception. You must have a 'try'
block to have a 'catch' block. What do you mean, "if failure is an option"?
Failure is an option means "try this, and if that doesn't work I have
something else you could try".
Oh, right. Well, a catch block is a small part of the mechanism to restore
sanity to the program so that higher-level logic can do that.
[snip]
So, if we don't ignore an Exception, what do we do with it?
Catch it, log it, and restore the program to a sane state. Sometimes that
means rethrowing the exception, but very rarely. More common is to recast
into an application catch-all exception. More common, or better practice in
more situations, is to provide an alternate return from the operation to
signal to the caller that there was a problem - that's where a buried
exception can be rethrown sometimes. It's a matter of art.
Checked exceptions should be converted to a non-exceptional situation and the
method gracefully exited.
Runtime exceptions are more serious, representing programmer error, and might
require abandonment of the operation or the program altogether, again, gracefully.
At the lowest level, an exception usually should be converted to a
non-exceptional condition after logging. Logging is vital.
Then a quick graceful exit from the low level, with a signal (like a bad
return value) to the caller, which gracefully does what you suggested earlier,
that is, create an alternate path for the operation or user or whatever.
If there's no alternative (if try block fails we have other code we
could try), then the only point to this would be if we want to throw
out a custom message?
You don't throw messages, you throw exceptions.
At the low level you usually do not emit messages, but return conditions to
higher-level code. You do not put much into 'catch' blocks at all - log,
clean up, get out, fast.
The higher level makes sense of that for either business logic or user
interaction.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg