Exception programming difficult

[SomeDude]

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.