Re: When to throw exceptions and when to use System.err?
On Mar 31, 10:58 am, Nigel Wade <nmw-n...@ion.le.ac.uk> wrote:
On 31/03/11 14:55, Eric wrote:
On Mar 30, 11:49 pm, Lew <no...@lewscanon.com> wrote:
Eric wrote:
There is a bad user input exception but the point is that it's a
program problem by the time it becomes an exception.
I agree with the point so I won't quibble with the phrasing.
If your program accepts the value of 12 from user input where it
expects a value no greater than 10, it's already gotten past the user
input program with incorrect or incomplete validation.
Which is not an input problem.
I would think printing (err.println) should only be for debugging, no=
t
necessary for live programs.
That would be entirely up to the specifications for the "live" program=
..
System.err.println() is not a good choice for debugging. It's not a=
terrible
choice for probing development alternatives, but it's still infelicito=
us. So
only use it where the application requirements call for it.
As for what's good for debugging, when debugging is called for, nothin=
g beats
a debugger. When it is not called for, you leverage the tools avail=
able to
the production environment, namely logs. Bear in mind when you writ=
e logging
code that its purpose is to support operations, and we developers ride=
on
those coattails. Logging should not be designed selfishly for a pro=
grammer's
convenience.
Your last point is an interesting question. Don't ignore exception=
s?
What does this mean?
That wasn't /my/ point. That was a chapter ("Item") title from /Eff=
ective
Java/ by Joshua Bloch, 2nd ed. Buy it. Study it.
Ignoring exceptions means exactly what the words denote: not paying at=
tention
to them.
There are two kinds of exceptions (by which I mean improper subtypes o=
f
'Exception'): runtime, or unchecked exceptions, and checked exceptions=
..
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?
There's a potential NPE which will be thrown if the caller passes in a
null String.
You didn't catch or throw any exceptions
there.
No, none were caught, but an NPE may be thrown.
Eclipse doesn't have any warnings or errors on that block,
other than the syntax error for the missing ).
It won't have. NPE is a RuntimeException so doesn't need to be declared,
or caught. It will, however, crash your program if it occurs and you
don't catch it.
--
Nigel Wade- Hide quoted text -
- Show quoted text -
Interesting you can crash that simple program by passing in null
instead of a String and Eclipse doesn't mention it.
So should every such error be thrown or trapped? It would seem such
error should be tracked down in the object where this method is
called, and trapping them all would be a real nuisance.
public void foo( String sometxt )
{
if (sometxt == null) {
throw new RuntimeException("That's a null not a String!");
}
System.out.println( "Input length "+ sometxt.length()
+" value\n\""+ sometxt +'"');
}
Which of these makes more sense?
public void foo(String fileName) throws Exception
{
try {
File myFile = new File(fileName);
myFile.createNewFile();
}
catch (Exception e)
{
throw e;
}
}
public int foo(String fileName)
{
int returnValue = 0;
try {
File myFile = new File(fileName);
myFile.createNewFile();
}
catch (Exception e)
{
returnValue = 1;
}
return returnValue;
}
Aside from tossing out numbers, the alternative to throwing the errors
would seem to be tracking down every possible reason for the error and
passing out..more numbers, or message strings?