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?
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?
