The Right Approach to Exceptions
Johannes Pfau
nospam at example.com
Mon Feb 20 11:54:21 PST 2012
Am Mon, 20 Feb 2012 11:13:29 -0800
schrieb Sean Kelly <sean at invisibleduck.org>:
> On Feb 20, 2012, at 9:55 AM, deadalnix wrote:
> >
> > 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.
> >
> > 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 think its debatable whether a Variant[string] or string[string] is
> ideal here, but either way I think the point of the table is for
> localized error messages. I wouldn't expect any data relevant for
> filtering the exception within the table.
>
I think this whole localization discussion is useless as long as we
have no std.localization module. For example this
Variant[string] / string[string] stuff could be part of a
TranslatedMessage struct, which could be used like this
auto msg = TranslatedMessage("Couldn't connect to IP %s", ip);
TranslatedMessage could then automatically convert ip to a string and
store it in a Variant[string] / string[string] internally. Then when
msg.toString() is called, TranslatedMessage would translate the format
string and use the entries in the Variant/string table to construct the
message. Exception could then simply store a TranslatedMessage and this
could be useful for other code, not only for exceptions. I don't see
why we should invent some special exception only localization now.
More information about the Digitalmars-d
mailing list