On 2/19/12 4:00 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu"<[email protected]> wrote in message
news:[email protected]...
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
