Re: When to throw exceptions and when to use System.err?
On 04/01/2011 01:44 PM, Eric wrote:
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?
Why did you ask this question a second time? Did you read my answer the first
time? For reference, again!, it was:
YES! You absolutely MUST track down EVERY possible reason for error and prevent it.
THAT'S PROGRAMMING!
Why would you ever do otherwise? Do you actually want to leave possibility for error in your program?
Really? Why?
Again, don't catch exceptions, prevent them. Do you recall that I posted upthread:
<http://java.sun.com/docs/books/effective/toc.html>
What part of that answer was not clear?
I want the program to crash if they pass in a null String. That means
NO!
That is a VERY STUPID idea.
Instead, have the program exit on errors. Even better, have it handle the
exception.
Don't do stupid things. Do smart things.
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"?
Invalid analogy. Just follow the advice. Did you buy and read /Effective
Java/ yet? If not, why are you still posting questions here?
Why should we give you more advice when you're not listening to the answers,
and we can't tell that you're following the advice?
I'm not seeing any warnings on that method. I have errors configured:
Null pointer access = Warning
Potential null pointer access = Warning
That method was not presented in an SSCCE. Would you please post your
complete version of that example?
Your statement indicates nothing.
Are you suggesting Oracle is wrong? I've gotten a number of
Exceptions thrown from their object methods. Someone aught [sic] to tell
them to start passing out error codes instead.
Sorry?
Those are library calls, not applications. Did you read /Effective Java/ yet?
Just be quiet and learn. You don't know enough to argue and be snarky like
that yet.
It sounds like your quote "Favor the use of standard exceptions" is
contrary to your message "recast into an application catch-all
exception".
I was laying out the different options. Some are better than others. The art
of programming involves knowing the risks and advantages, limitations and
powers of each approach. STUDY THE RECOMMENDED MATERIAL BEFORE POSTING.
It'll save you much embarrassment.
To what extent? If every object checked for every possible error and
YES!
You failed to answer my questions, yet you keep asking more. FOUL!
HANDLE *ALL* ERRORS!
What part of that answer was unclear before?
Did you study /Effective Java/ yet?
You don't throw messages, you throw exceptions.
Semantics. As my previous example:
Semantics are important. Why do you pretend that they are not?
throw new RuntimeException("That's a null not a String!");
You're throwing a custom message as an exception.
No, you are not.
You are throwing an exception that contains a string. You are not throwing a
message, in Java terms. Yes, O-O defines all interactions as messages, so in
a sense you are throwing a message, but that is not the terminology.
You pretend to want to learn, but you don't follow the recommendations, you
don't answer questions, you argue without knowledge, and you decline to use
the correct terminology. If you are already such an expert, why are you
asking for information?
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.
That is one alternative. Why do you think it's the only one?
Stop arguing from ignorance.
Answer questions, follow advice, READ THE BOOK.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg