The Right Approach to Exceptions

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun Feb 19 15:04:59 PST 2012


On 2/19/12 4:00 PM, Nick Sabalausky wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail at erdani.org>  wrote in message
> news:jhrn3r$fie$3 at digitalmars.com...
>> On 2/19/12 12:49 PM, Nick Sabalausky wrote:
>>> No, exceptions need to be based around semantics, not modules.
>>
>> Packages and modules are also organized around specific areas.
>>
>
> And those specific areas do NOT necessarily correspond 1-to-1 to error
> conditions.

They don't; the intent here is, again, to cater to the common case.

> 1. A module can still reasonably generate more than one conceptual type of
> exception. Ex: std.file can be expected to generate both "file not found"
> and "disk full" conditions (those may both be IO exceptions, but they're
> still separate issues that are *not* always to be dealt with the same way).

Sure. That would mean std.file could define

// inside std.file
class FileNotFound : public ModuleException!.stringof
{
     ...
}
class DiskFull : public ModuleException!.stringof
{
     ...
}

Or could define one:

// inside std.file
class FileException : public ModuleException!.stringof
{
     Code code;
     ...
}

> 2. As I *already* explained in further detail, it's perfectly reasonable to
> expect one specific area to be convered by more than module.
>
> Therefore, "Modules" to "Conceptual types of exceptions" are not 1-to-1.
> They're not even 1-to-many or many-to-1. They're many-to-many. Therefore,
> module is the wrong basis for an exception.

I think that direction is worth exploring.

> Seriously, how is this not *already* crystal-clear? I feel as if every few
> weeks you're just coming up with deliberately random shit to argue so the
> rest of us have to waste our time spelling out the obvious in insanely
> pedantic detail.

It sometimes happened to me to be reach the hypothesis that my 
interlocutor must be some idiot. Most often I was missing something.


Andrei


More information about the Digitalmars-d mailing list