The Right Approach to Exceptions

[Jacob Carlborg]

On 2012-02-21 01:51, H. S. Teoh wrote:
> 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
>

I completely agree.

-- 
/Jacob Carlborg