On Sunday, February 19, 2012 17:00:24 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. > > 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). > You can argue till your keyboard wears out that you don't see the > usefulness, but the fact is, many, many, many people DO find it useful. > > 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. > > 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.
While I think that Nick is getting a bit incensed and even a bit rude in some of his posts in this thread, I completely agree with his basic point here. In a well-designed exception hierarchy, the exception types are based on the types of things that went wrong. That way, you can catch them based on what went wrong, and they can provide information specific to that type of problem. As such, there is not necessarily any connection (let alone 1:1) betwen exception types and modules. You could have multiple exception types per module or have several exceptions sharing a module. And if the exception hierarchy is done particularly well, then code which uses Phobos will also throw those exceptions when appropriate. For instance, in other languages, InvalidArgumentException is quite commonly used to indicate that a function was given bad arguments when an exception is thrown for that sort of thing - and code outside of the standard libraries uses it for that purpose all the time. We have as much of a connection between modules and exceptions as we do, because Phobos is generally well-organized according to functionality, and different functionality tends to mean different exception types. But we've also taken it too far in some cases, creating an exception type in a module simply because most Phobos modules have their own exceptions. Ultimately, it's what went wrong that matters, _not_ in which module it happened in. And if anything, we need to redesign what we have so that it better follows that, getting rid of some exceptions, merging others, and in some cases creating new ones. In many cases, you'll still have an exception per module, but in some cases you'll end up with multiple, and in others, you'll end up with none, because those modules are using exceptions from other modules. - Jonathan M Davis
