The Right Approach to Exceptions

Andrei Alexandrescu SeeWebsiteForEmail at
Mon Feb 20 10:00:11 PST 2012

On 2/20/12 11:55 AM, deadalnix wrote:
> Le 20/02/2012 18:11, Andrei Alexandrescu a écrit :
>> On 2/20/12 11:05 AM, foobar wrote:
>>> On Monday, 20 February 2012 at 16:37:28 UTC, Andrei Alexandrescu wrote:
>>>> On 2/20/12 10:16 AM, Nick Sabalausky wrote:
>>>>> "Andrei Alexandrescu"<SeeWebsiteForEmail at> wrote in message
>>>>> news:jhtq31$u8q$1 at
>>>>>> 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.
>>>> How would we address custom formatting of e.g. error messages?
>>>> Andrei
>>> Separation of concerns - exceptions are meant to notify the *developer*
>>> of errors. User facing error messages is a separate concern that
>>> exceptions should not be responsible for. it's not just outsourcing the
>>> translation strings, it's the developer's job to determine what if at
>>> all should be done with the exception.
>> At the end of the day, a human-readable error message must be properly
>> formatted given some exception that signaled an error. So I disagree
>> that exceptions are meant for the developer. They are mechanism, a means
>> to an end.
>>> Trivial example: My mom enters a misspelled URL (e.g. in her
>>> browser, she does not know or care what 404 means. instead she gets a
>>> formated page suggesting her to check her spelling and probably a
>>> suggestion to try instead.
>> Sure, and the question is how the message gets created.
>>> the exception notifies the developer of the error, the developer does
>>> extra processing (e.g. to suggest similar valid websites) and the user
>>> get a friendly notification. clearly it doesn't make sense to put all
>>> this into the exception.
>> That extra processing must format the message given the information
>> passed by the exception. _Definitely_ it doesn't make sense to put the
>> formatting processing in the exception. That's why shipping the
>> information outside the exception in a generic format is necessary,
>> hence the Variant[string].
>> Andrei
> And so variant is the way to go ?
> Clearly, this is a very strong arguement in favor of typed Exception,
> that provide usefull information about what went wrong. This is a safe
> approach.

This does not pit typed exceptions against uniform interfaces. The hash 
simply provides information in a uniform format across exception types. 
That way, code that needs to extract and format information in a generic 
manner can be written in one place.

> Because this Variant stuff is going to require massive ducktyping of
> Exceptions, with all possible errors involved. The keys in the
> Variant[string] will depend on the Exception the dev is facing. This
> should be avoided and should warn us about the requirement of typed
> Exceptions.

I agree. Again, this is not one against the other.


More information about the Digitalmars-d mailing list