Re: When to throw exceptions and when to use System.err?
On Mar 31, 7:50 pm, Lew <no...@lewscanon.com> wrote:
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.
That sounds like an exception which should never happen. Do you
program for every possible exceptions or just the rational ones?
I want the program to crash if they pass in a null String. That means
the object which called that method is invalid.
If you design a truck for a dog catcher who should only ever have dogs
in the truck, do you need a warning sign "loading any elephants in
this truck will break it"?
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 nul=
l
pointer warnings.
I'm not seeing any warnings on that method. I have errors configured:
Null pointer access = Warning
Potential null pointer access = Warning
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 res=
tore
sanity to the program so that higher-level logic can do that.
Are you suggesting Oracle is wrong? I've gotten a number of
Exceptions thrown from their object methods. Someone aught to tell
them to start passing out error codes instead.
[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 t=
hat
means rethrowing the exception, but very rarely. More common is to rec=
ast
into an application catch-all exception. More common, or better practi=
ce 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.
Now you're sending mixed messages. Catch the error just to rethrow
it, recast it, or set a variable and hope the object which called the
method bothered to check the return code?
try {
testcode();
}
catch (Exception e) {
throw new MyAppException(e);
}
It sounds like your quote "Favor the use of standard exceptions" is
contrary to your message "recast into an application catch-all
exception".
"That achieves exactly nothing. NPE already is a RuntimeException."
means you're suggesting don't crash for null Strings just log it and
return out quietly hoping whoever called your method knows or doesn't
care?
"You absolutely MUST track down EVERY possible reason for error and
prevent it." is the responsibility of every object, or every object
which calls the object? Are you just wasting time putting "do not
drink" labels on a bottle of motor oil and "do not plug with a potato"
on the tailpipe?
Checked exceptions should be converted to a non-exceptional situation and=
the
method gracefully exited.
Runtime exceptions are more serious, representing programmer error, and m=
ight
require abandonment of the operation or the program altogether, again, gr=
acefully.
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 ear=
lier,
that is, create an alternate path for the operation or user or whatever.
To what extent? If every object checked for every possible error and
passed out a number or string to identify any errors, there would be
no need for a throw verb.
I tend to expect if you're writing a method in an API to be used by
other objects, those objects should check for any errors they might
encounter.
If I'm writing a File.createNewFile method, I shouldn't have to have a
long conditional statement to return the value of any possible error
(file name is incorrect, path is invalid, drive is unavailable, object
doesn't have permission to write, file already exists, file name
variable is null, etc).
Then if you pass out a value instead of crashing and you have another
method which requires that value as input you have to validate it
again even though the object calling your methods just got the value
from you so they already know it's valid.
I tend to think you can just go overboard on validation especially on
low level methods. Passing out a string to clarify the error instead
of throwing the error should be most useful on the user level, if
they're running it from a command line.
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.
Semantics. As my previous example:
throw new RuntimeException("That's a null not a String!");
You're throwing a custom message as an exception.
The alternative is returning a message if you have a string or an
object containing a string in the normal return value, and assume
anyone calling the method is checking the return string if they need
to.
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 - lo=
g,
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
Do you have an example of that "log, clean up, get out"? If it's
doing the same thing for every error why have a try catch in the first
place, they should have a method to tell it what to do on errors for
the entire object.