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
