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"<seewebsiteforem...@erdani.org> wrote in message
news:jhtq31$u8q$1...@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
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.
Andrei
