The Right Approach to Exceptions
deadalnix at gmail.com
Mon Feb 20 10:21:27 PST 2012
Le 20/02/2012 19:02, Andrei Alexandrescu a écrit :
> On 2/20/12 11:28 AM, Jose Armando Garcia wrote:
>> On Mon, Feb 20, 2012 at 2:37 PM, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail at erdani.org>>
>> On 2/20/12 10:16 AM, Nick Sabalausky wrote:
>> "Andrei Alexandrescu"<SeeWebsiteForEma__il at erdani.org
>> <mailto:SeeWebsiteForEmail at erdani.org>> wrote in message
>> news:jhtq31$u8q$1 at digitalmars.__com...
>> Again, I think this thread clarified we need the
>> "Variant[string] info;"
>> member however we define the hierarchy.
>> I disagree. I don't see a need for that.
>> How would we address custom formatting of e.g. error messages?
>> This may not be D. Gettext says to solve it as follow:
>> throw new Exception(gettext("Cool English message at
>> The gettext "compiler" goes through the code an generates all the
>> strings that need to be localized. The translation teams modifies those
>> string and you store them in file/map for that language. At runtime the
>> i18n library turns gettext(...) into a query into that map and returns
>> the actual localized string. There is a map for the entire process.
>> Localization can also be disable at compile time by making gettext a
>> template and generating a "noop" for that operation.
> So this moves formatting from the catch point to the throw point. That's
> fine, but it forces the formatting effort upfront even when the message
> is not actually used and leads to duplication because each call site
> would need to provide the message entirely. I think it's worth
> investigating formatting at the catch site.
This is not the way we want to go. You have a piece of code to describe
what the problem is, another to descide what to do with that problem and
again another to do something that may go wrong.
Formatting is an error handling problem, and so formatting at the throw
point is a bad separation of concerns.
Plus, the way you want to format stuff is likely to depend on the
More information about the Digitalmars-d