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.