Exception programming difficult

Kagamin spam at here.lot
Thu Aug 16 03:36:59 PDT 2012


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?


More information about the Digitalmars-d mailing list