The Right Approach to Exceptions

[Andrei Alexandrescu]

On 2/20/12 1:38 AM, Jonathan M Davis wrote:
> On Monday, February 20, 2012 01:10:39 Andrei Alexandrescu wrote:
>> ModuleException and PackageException have one important thing going for
>> them: they automate away a good amount of boilerplate, which makes them
>> interesting for me to look at, and worth sharing as long as we're
>> brainstorming. The associated issues as clear as the advantages.
>> Probably ModuleException is too specific to be interesting, but
>> PackageException seems useful.
>
> It saves no boilerplate at the catch point, because you have to know what
> you're catching to do anything useful with it. It could be that you choose to
> catch a common exception rather than a specific one (e.g. IOException instead
> of FileException), but regardless of whether you use templates or mixins or
> whatever to generate the exception type's source code, you still need to write
> the handling code by hand. Handling code is _not_ the sort of thing that can
> be automated.

Absolutely. For catching we're looking for allowing centralization, not 
for automation.

> And as for saving boilerplate in defining exceptions, well some of that could
> be done via mixins, but since useful exceptions often have additional member
> variables, you're going to have to write many of them by hand anyway.

Again, I think this thread clarified we need the "Variant[string] info;" 
member however we define the hierarchy.

Also, I think we can do better than defining the boilerplate constructor 
(see e.g. https://github.com/D-Programming-Language/phobos/pull/439). 
It's just a function. Consider:

// this goes in the stdlib
void raise(ConcreteException)(string message, Throwable t = null, string 
f = __FILE__, size_t l = __LINE__)
{
   auto r = new ConcreteException;
   r.message = message;
   r.file = f;
   r.line = l;
   r.next = t;
   throw r;
}

class AcmeException : Exception {}

Now whenever you want to raise AcmeException, you say 
raise!AcmeException("message"). Also, raise may accept additional data 
that fills the Variant[string]. That makes exception definitions one-liners.

> And as has been said before, ultimately the module that an exception comes
> from doesn't mean much. It's what went wrong that matters. And ideally, the
> standard library would have exception types that user code would throw or
> derive its own exception types from, in which case the exception types get
> even more divorced from the modules that they're declared in. So, ultimately,
> tying exceptions to modules or packages is _not_ a good idea in the general
> case. Sometimes it makes sense - particularly if you're talking about making a
> base exception type which a project as a whole uses (e.g. a PostgresException
> for a postgres library) - but in general, it's a bad approach, and it's one
> that we should be moving away from.

I tend to agree, particularly because it's easier for people to remember 
express names instead of origins encoded by module. Ironically, many of 
Phobos' exceptions today follow the exception-to-module correspondence. 
Still I think it's worth keeping in mind the possibility of having the 
PackageException as a base trail for various exceptions specific to a 
package.


Andrei