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"<[email protected]> wrote
in message
news:[email protected]...
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.
