Re: When to throw exceptions and when to use System.err?
On Apr 1, 7:52 pm, Lew <no...@lewscanon.com> wrote:
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 an=
d 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 th=
e 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 th=
e first
time? For reference, again!, it was:
I ask again because you gave 2 conflicting answers.
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 possi=
bility for error in your program?
Really? Why?
Again, don't catch exceptions, prevent them. Do you recall that I po=
sted upthread:
<http://java.sun.com/docs/books/effective/toc.html>
What part of that answer was not clear?
The part where you said all possible errors should be caught and every
method should exit normally passing out values for every possible
error not throwing anything, then you say it's good to throw errors
because if it were not good practice then the Java API would not do
it, the java.io.File.read() would not crash if the file were
unavailable or the program didn't have access to it, it would exit
gracefully passing out a value to let your program know exactly what
the problem is.
I want the program to crash if they pass in a null String. That mean=
s
NO!
That is a VERY STUPID idea.
Instead, have the program exit on errors. Even better, have it handle =
the
exception.
That sounds like good practice for an end user application program.
I'm writing a program which will only be called by other programs,
where it should be safe to assume the input is already valid or else
the calling program/object is incorrect. If we pass in a String which
should always be a String why waste time checking if it's a null?
Don't do stupid things. Do smart things.
Writing redundant code which has a class with a method to be used by
other objects and tells what values to pass in then validates those
values which should already be valid doesn't seem so smart.
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 /Effe=
ctive
Java/ yet? If not, why are you still posting questions here?
Where do I get a free copy of that book? I don't have money for
books.
Why should we give you more advice when you're not listening to the answe=
rs,
and we can't tell that you're following the advice?
I am trying to listen but we are not communicating. Either you're
writing something wrong or I'm reading it wrong. I don't see any
straight answer to my question.
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?
What was not SSCCE? I just said Eclipse returns no error on your
method which you claim should get the NPE.
public void foo( String sometxt )
{
System.out.println( "Input length "+ sometxt.length()
+" value\n\""+ sometxt +'"');
}
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 Jav=
a/ yet?
Now the throw/throws verbs are not to be used outside of Oracle's
code?
Just be quiet and learn. You don't know enough to argue and be snarky =
like
that yet.
I am trying to learn. I apologize if that sounds "snarky" when I ask
a question and get a response which appears confusing or conflicting
and express some of my frustration in an attempt to clarify.
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.
Am I understanding correctly yet, you're saying Java lets you do a lot
of things you shouldn't do, and provides methods which don't catch
errors so you can repeatedly figure out what those errors might be and
catch them yourself every time you use the methods, and the common
practice of throwing errors as used by major open source collaboration
projects is incorrect?
http://docjar.com/docs/api/org/apache/fop/apps/FOPException.html
So to the original question "When to throw exceptions and when to use
System.err?" your answer is "never, errors on any level should be
passed values on the return statement".
You may be the most knowledgeable Java programmer in the world but
writing about it with intent to teach is pointless if you can't make a
student understand, and the forum is pointless if every question is
answered with "don't bother asking, go buy a book and read until you
figure it out yourself".