The Right Approach to Exceptions

[Andrei Alexandrescu]

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 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.
>>
>> 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. goggle.com) 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 google.com 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