On Thursday, 16 August 2012 at 10:37:01 UTC, Kagamin wrote:
On Wednesday, 15 August 2012 at 17:44:14 UTC, SomeDude wrote:
Or you could have told him HOW he messed up. By just throwing
an Exception, you are not helpful at all, you are just telling
that he is an ass and that he will be punished for that. Or
maybe he will curse you thinking that your program doesn't
work.
Let's say I write a FileParser class which will read a table
of doubles in a file. I use a number of methods defined in the
JDK like say Double.parse(String) which throws a
NumberFormatException("on line" + lineNumber), and catching
that exception, I am able to tell the user that one of the
numbers on line lineNumber is badly formatted, instead of just
telling him that reading the file with 200,000 lines crashed
the program.
How checked exceptions would help you decide whether line
number should be included in the error message?
You didn't get my point because it was badly formulated. I wanted
to emphasize here that because the exception is typed, you can
give a better information on what is wrong (here a bad
formatting, and you throw in the line number). The interface of
Double.parse() *forces* you to catch that exception, and that is
a *good* thing. If it didn't force you to catch it, you would
lazily 1) not catch and let the program crash 2) catch an
Exception and not be able to tell the user what's the root cause
of the error, leaving him scratching his head and thinking that
your program is actually at fault (because it failed) and not the
file.
So in a sense, Double.parse(), by throwing a
NumberFormatException, forces you to be precise in your error
handling and to think about it, i.e answer the questions:
a) must I handle the exception or pass it to another level where
it makes sense to handle it
b) how can I provide the best information as to how to handle the
situation.
Just placing a catch all Exception at the top level is obviously
not enough, because all it says is "something went wrong". It
doesn't help handling the error at the right place, in the
correct manner.
It's a misconception that is all too common in the C++ world
because in C++, exceptions are so crippled that they are
basically unusable, so people resort to the catch all trick,
which is most often less than useless.
If I catch an IOException as well, I can inform him that the
file is unreadable instead (but that the formatting was not
yet in cause). But if I catch a FileNotFoundException first
(which derives from IOException), I can be more helpful by
informing him/her that the filename passed to the program is
wrong.
How checked exceptions would help you design exception
hierarchy? What's your point?
The exception hierarchy helps choosing the right level of
"graininess" in error handling depending on how you want the user
to handle errors. You may want to help him establish a diagnosis,
in which case you will throw the most discriminating exceptions,
or you may just want to inform him that something went wrong, in
which case you will rather throw a root exception class. This is
very similar to the choice you make when writing logs and choose
their log level. Because checked exceptions force you to catch
them, you can catch exceptions high in the hierarchy in order to
avoid catching every single leaf, which is the case if you are
not interested in handling all these different cases.
