Boost logo

Boost :

Subject: Re: [boost] [locale] Formal review of Boost.Locale library starts tomorrow
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-04-16 21:52:55


On Sat, Apr 16, 2011 at 12:53 PM, Artyom <artyomtnk_at_[hidden]> wrote:

> > From: "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung_at_[hidden]>
> > > > Could the error behavior be specified in the call to
> > > boost::locale::format?
> > > >
> > >
> > > I explain, the error of for example missing parameter is almost never
> > > a error, consider following:
> > >
> > > format(translate("Passed {1} day", "Passed {1} days",n)) % n;
> > >
> > > Now in Hebrew it would have 3 plural forms: single, dual and plural
> > >
> > > עבר יום {1}‏ /passed {1} day
> > > עברו יומיים /passed two-days when "two-days" is a single world -
> no
> > > parameter used
> > > עברו {1} ימים / passed {1} days
> > >
> > > So missing parameter is ok in localization context, while
> boost::format
> > > throws
> > > unless you do something specific.
> > >
> >
> > So that's the specific case of a missing parameter error, but is this
> the
> > only kind of error one can make with boost::locale::format? If not,
> it's
> > not really a convincing argument that all users all the time would like
> > boost::locale::format to ignore all errors. And you do qualify that
> this
> > particular error is "almost never a error", leading me to believe that
> > sometimes it really is an error you care about.
> >
>
> I'll explain, Boost.Locale format may throw if for example
> io-operations fail or streaming object to file causes an exception
> or bad_alloc is thrown.
>
> However it never throws in case of syntax error, missing
> parameter or extra parameter.
>
> This point was also told before and I'll document it more explicitly.
>
> I explain the rationale:
>
> Usually boost.format is going to be used as:
>
> format(translate("something")) % a % b % c
>
> Now, how translation process goes. Translator
> takes a dictionary, defines the locale and loads
> it.
>
> Translator is not a programmer, but he looks on
> output.
>
> So I can expect that it would accidentally
> screw the format by writing:
>
> "{1,numb}" instead of {1,num} or {1,number}
>
> If boost.format throws it may accidentally stop
> the program and both translator and programmer
> would give very hard times to understand what
> is going.
>

Okay, I can buy that in some circumstances, you want syntax errors to be
silently ignored. This appears to be mostly because the allowable syntax
can vary with the runtime locale; is that correct? (I've only skimmed the
first few pages of the documentation so I should probably go through it more
thoroughly. I was completely unfamiliar with localization until this review
came up.)

So by no means the formatting string should cause
> an exception, it may cause invalid output that
> the translator would see and fix but not abort
> the entire program.
>

Based on your knowledge and experience in this domain, I take it at your
word that swallowing syntax errors is the typical use case. But I'm
skeptical that this use case is the only relevant one for all users all the
time. You haven't given any argument against simply opening up the
interface to allow the user to specify the error behavior, with the default
being to swallow the error. To me, this wouldn't change the typical use
case, and, on the implementation side, I wouldn't expect it to be
technically challenging.

I do appreciate you taking the time to bear with me and to explain to me in
detail your rationale.

- Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk