The Right Approach to Exceptions

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Feb 20 11:49:09 PST 2012


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.


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte


More information about the Digitalmars-d mailing list