On Sat, Apr 16, 2011 at 12:53 PM, Artyom <artyomtnk@yahoo.com> wrote:
From: "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com>
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