Re: When to throw exceptions and when to use System.err?
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, 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 te=
rrible
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 b=
eats
a debugger. When it is not called for, you leverage the tools availabl=
e to
the production environment, namely logs. Bear in mind when you write l=
ogging
code that its purpose is to support operations, and we developers ride on
those coattails. Logging should not be designed selfishly for a progra=
mmer'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 /Effect=
ive
Java/ by Joshua Bloch, 2nd ed. Buy it. Study it.
Ignoring exceptions means exactly what the words denote: not paying atten=
tion
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 all=
ow
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 met=
hod to
damage the caller.
What runtime exception? You didn't catch or throw any exceptions
there. Eclipse doesn't have any warnings or errors on that block,
other than the syntax error for the missing ).
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 usua=
lly
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 't=
ry'
block to have a 'catch' block. What do you mean, "if failure is an opt=
ion"?
Failure is an option means "try this, and if that doesn't work I have
something else you could try".
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 me=
thod
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 exceptio=
n with
the strategy you describe? What are they supposed to do with it? Wh=
y didn't
the method you defined deal with it?
Why do you seek to avoid dealing with exceptions? The whole point of M=
r.
Bloch's advice not to ignore exceptions is NOT TO IGNORE EXCEPTIONS.
--
Lew
So, if we don't ignore an Exception, what do we do with it?
For example,
public void foo(String fileName)
{
File myFile = new File(fileName);
myFile.createNewFile();
}
We get an error "Unhandled Exception type IOException".
We can just modify the constructor,
public void foo(String fileName) throws Exception
(or IOException if we import the specific Exception)
If I try it to catch, then what?
public void foo(String fileName) throws Exception
{
try {
File myFile = new File(fileName);
myFile.createNewFile();
}
catch (Exception e)
{
throw e;
}
}
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?