The Right Approach to Exceptions

Nick Sabalausky a at a.a
Mon Feb 20 08:16:06 PST 2012


"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:jhtq31$u8q$1 at digitalmars.com...
>
> Again, I think this thread clarified we need the "Variant[string] info;" 
> member however we define the hierarchy.
>

I disagree. I don't see a need for that.

> 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.
>

So instead of solving a much more general problem with a clean 
definition-side-only solution, you'd rather tell people "Our langauge has 
'throw' like any other modern langauge. Exept that many exceptions need to 
be used with this 'raise' thing instead of 'throw'."

Why do you keep optimizing for API creators at the expense of API users?




More information about the Digitalmars-d mailing list