The Right Approach to Exceptions
Nick Sabalausky
a at a.a
Mon Feb 20 12:25:59 PST 2012
"H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote in message
news:mailman.704.1329767254.20196.digitalmars-d at puremagic.com...
> On Mon, Feb 20, 2012 at 08:36:56PM +0100, Andrej Mitrovic wrote:
>> On 2/20/12, Juan Manuel Cabo <juanmanuel.cabo at gmail.com> wrote:
>> > will be trouble. Instead please do:
>> >
>> > "The '%1$s' file's size is %2$d which is wrong"
>> >
>>
>> That is the shittiest formatting specifier ever invented. The
>> unreadability of it is why I never, ever, use it. Python solved this
>> nicely with its {0} {1} syntax:
>>
>> >>> print '{0} and {1}'.format('foo', 'bar')
>
> Actually, even that isn't ideal. How is the translator to know what on
> earth {0} and {1} are? Sometimes you need to know in order to make a
> good translation. This would be even better:
>
> "The ${file}'s size is ${size}, which is wrong"
>
> The usefulness of named arguments is even more apparent in complex
> message like this one:
>
> "${file}:${line}: Expecting ${expectedtoken}, got ${inputtoken}"
>
> Without named parameters, you'd have:
>
> "{0}:{1}: expecting {2}, got {3}"
>
> which is almost impossible to translate. What are {0} and {1}? What are
> {2} and {3}? Does it mean "12:30pm: expecting program to succeed, got
> general protection fault"?
>
> Using named parameters makes it clear this is a parser error, not
> something else. This difference may mean using a completely different
> grammatical structure to translate the message.
>
vote++; I've been drooling over the idea of named argument format strings in
D for a long while.
I also agree with posix-style specifiers being barely readable. I fell in
love with C#'s "Hello {1}" style at first sight, and was thrilled that Tango
adopted it. Then I moved to Phobos2, and have been missing those wonderful
curly braces ever since.
More information about the Digitalmars-d
mailing list