Re: When to throw exceptions and when to use System.err?
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, not
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 infelicitous. So
only use it where the application requirements call for it.
As for what's good for debugging, when debugging is called for, nothing beats
a debugger. When it is not called for, you leverage the tools available to
the production environment, namely logs. Bear in mind when you write logging
code that its purpose is to support operations, and we developers ride on
those coattails. Logging should not be designed selfishly for a programmer's
convenience.
Your last point is an interesting question. Don't ignore exceptions?
What does this mean?
That wasn't /my/ point. That was a chapter ("Item") title from /Effective
Java/ by Joshua Bloch, 2nd ed. Buy it. Study it.
Ignoring exceptions means exactly what the words denote: not paying attention
to them.
There are two kinds of exceptions (by which I mean improper subtypes of
'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.
With checked exceptions you can do the same thing by declaring the method to
throw the exception. This forces the caller to deal with it, though at least
you're warning it that it has to. But unless the method generates that
exception itself, it's usually cheating to let it up out of the method.
The other way to ignore exceptions, applicable to checked exceptions usually
but it works for runtime exceptions also, is to catch the exception, then
ignore it.
public void foo( String sometxt )
{
BufferedReader fr = null;
try
{
BufferedReader fr = new BufferedReader( new FileReader( sometxt ));
for ( String line; (line = fr.readLine()) != null; )
{
System.out.println( line );
}
}
catch ( IOException ioe ) {}
finally
{
if ( fr != null )
{
try
{
fr.close();
}
catch ( IOException ioe ) {}
}
}
There is a lot of ignorance in that example.
Is a try block necessary to catch an exception or only if failure is
an option?
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"?
Does the catch block normally have code you could try if the code in
the try block fails?
No.
If all you're going to do with the error is throw it out / inform the
Those are two different things.
calling program, could you should you leave out try and just add
It's not a calling program, it's a calling expression inside a calling method
in the same program.
"throws Exception" to the method declarations?
No. You can, but it would be bad.
When you declare a checked exception, you are telling the callers of that
method to deal with it. Whom are you telling to deal with the exception with
the strategy you describe? What are they supposed to do with it? Why didn't
the method you defined deal with it?
Why do you seek to avoid dealing with exceptions? The whole point of Mr.
Bloch's advice not to ignore exceptions is NOT TO IGNORE EXCEPTIONS.
--
Lew