The Right Approach to Exceptions

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Feb 20 16:51:00 PST 2012


On Mon, Feb 20, 2012 at 06:19:32PM -0600, Andrei Alexandrescu wrote:
> On 2/20/12 5:46 PM, Nick Sabalausky wrote:
[...]
> >You've suggested adding "Variant[string] info" to Exception for the
> >sake of i18n. I think that's what he's referring to. You *could*
> >argue that's not technically i18n, but so far i18n seems to be the
> >only real use-case for it (although even that much has been disputed
> >in light of reflection).
> 
> All formatting and rendering of the exception information is helped.
> And I think that's great because that's the most common activity one
> would do with exceptions.
[...]

Then, obviously, different development environments are leading to
vastly different conclusions, because I can't for the life of me imagine
that the most common activity you would do with an exception is to print
it.  That may be true for a certain class of applications, say
command-line tools like compilers and stuff. But that's absolutely not
the case at my work project. There, exceptions are usually handled by
code and almost never output anywhere, and even when they are, for the
most part they just print a simple string literal right from the source
code into a debug log channel. Only a tiny percentage of exceptions
actually make it all the way to being formatted into a nice localized
string displayed to the user.

For the more common case of printing to the debug log, the current
Exception facilities (string msg) are more than good enough (since the
intended audience is the developers themselves). The i18n stuff is
handled by catching the relevant exception by type and looking up the
localized string at the catcher level. Any additional info inside the
exception object itself isn't used for formatting the localized string
anyway, since the user has no idea what it all means.


T

-- 
The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners... -- Slashdotter


More information about the Digitalmars-d mailing list