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