The Right Approach to Exceptions
Alex Rønne Petersen
xtzgzorex at gmail.com
Sat Feb 18 13:25:03 PST 2012
On 18-02-2012 21:36, H. S. Teoh wrote:
> On Sat, Feb 18, 2012 at 08:20:23PM +0100, deadalnix wrote:
> [...]
>> However, in D, I think this is more the role of an Errors. Exception
>> are something « softer ». It will alert you on problems your program
>> encounter, but that are recoverable.
>
> I agree.
>
>
> [...]
>> Let's get an exemple : your program ask a file to the user and do some
>> operations with this file. If the file doesn't exists, you can prompt
>> for another file to the user with a meaningful message and start
>> again. However, the first version of your program can just ignore that
>> case and fail with a less specific handler in firsts versions.
>>
>> You cannot achieve something like that if you don't have a useful
>> type to rely on. Here something like FileNotFoundException is what
>> you want.
>
> Exactly. It's important to distinguish between exceptions sometimes.
> For example:
>
> File promptSaveFile() {
> do {
> string filename = readInput();
>
> try {
> return File(filename);
> } catch(FileNotFoundException e) {
> writeln("No such file, please try "
> "again");
> }
> } while(true);
> assert(false);
> }
>
> It would not make sense for that catch to be *any* Exception; for
> example, if the exception was ReadFailureException, you do *not* want to
> catch that, but you want to propagate it.
>
> But sometimes, you *want* to handle ReadFailureException, for example:
>
> void salvageBadSector(out ubyte[] sector) {
> int n_attempts = 10;
>
> while(n_attempts> 0) {
> try {
> disk.read(sector);
> } catch(ReadFailureException e) {
> disk.recalibrate();
> n_attempts--;
> continue; // try again
> }
> // If another error occurs, say OutOfMemory,
> // or some other unexpected problems, you do NOT
> // want to continue.
> }
>
> writeln("Cannot salvage data from bad sector");
> }
>
> Having distinct exception types allows you to do this without resorting
> to hacks, or bypassing the library altogether (because of the use of
> overly generic exception types).
>
> Having a proper exception class hierarchy is also necessary. For
> example, most programs don't care about the difference between
> FileNotFoundException and ReadFailureException; they just want to print
> an error message and cleanup if I/O fails:
>
> Data loadData() {
> try {
> return readFromFile();
> } catch(IOException e) {
> writeln("I/O error occurred, aborting");
> cleanup();
> exit(1);
> }
>
> assert(false);
> }
>
> It would be wrong to just catch Exception here, because if it wasn't an
> I/O error, but something else, it needs to be propagated!
>
>
>> The type of the exception must depend on the problem you are facing,
>> not on the module that trhow it. I see a lot of people doing the «
>> MyProgramException » or « MyLibException » but that doesn't make
>> sense. In this case, you are just making things harder.
>
> Agreed.
>
>
> [...]
>> If this politic is choosen, then It would make sense to have several
>> modules of phobos throwing exceptions of the same type, or inheriting
>> from the same base class.
>
> Phobos NEEDS to have a sane exception hierarchy. ESPECIALLY since it is
> the standard library. So you cannot assume your users cares or don't
> care about distinguishing between exception types. Some applications
> just catch Exception, cleanup and exit, but other applications need to
> know the difference between FileNotFoundException and
> ReadErrorException.
>
> So we need to design a good exception hierarchy for Phobos.
>
> The worst thing is if Phobos exceptions are too generic, then
> applications that need to tell between different problems will have to
> bypass Phobos and hack their own solution. Which is not good. The
> standard library should be maximally useful to the extent that it can
> be.
I'd just like to add to this that we don't lose anything per se by
introducing specific exception types. People can still catch Exception
if they really, really want.
>
>
>> Exception type is a convenient way to filter what you catch and what
>> you don't know how to handle at this point.
>
> Agreed.
>
>
> T
>
--
- Alex
More information about the Digitalmars-d
mailing list