The Right Approach to Exceptions

[foobar]

On Monday, 20 February 2012 at 17:11:09 UTC, Andrei Alexandrescu 
wrote:
> 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

This extra processing is orthogonal to the exception. the same 
exception can be logged to a file, processed (per above example) 
and generate graphical notification to the user, etc. The 
exception contains the information pertaining only to what went 
wrong. the rest is not part of this discussion.
The exact same exception in the example would also be thrown on a 
mistyped URL in an application that tries to scrape some info 
from a website for further processing. The error is still the 
same - the url is incorrect but different use cases handle it 
differently. In the former example I might call to a i18n lib 
(someone already mentioned gettext) while in the latter I'll call 
a logging library with the the mistyped url (for statistics' 
sake).
in the first I use the url to find a closest match, in the second 
I want to log said requested url. Both handled by *other* 
mechanisms.
in both cases the exception needs a url field and in both cases I 
have no need for the Variant[string] map.