Tuesday, 26 April 2011

Assuming culture

I've just had an interesting bug report for Aussie Toilets. The stack trace starts with this:

System.Reflection.TargetInvocationException: TargetInvocationException ---> System.FormatException: FormatException
à System.Decimal.Parse(String s, NumberStyles style, IFormatProvider provider)
à Gardiner.PublicToilets.Services.DataService.<LoadManifest>b__3(XElement x)

There's a small clue there, but the other big hint was the user's regional setting:

Culture: fr-FR

It turns out in a number of places I'd been assuming the default number format, particularly instances of Decimal.Parse(), Convert.ToDouble(), and the popular String.Format().

So if you're in France, you'd be used to seeing "123.49" written as "123,49". The bug in the application was that the data being read was originally formatted in the former, but with the user's regional settings set to 'French (France)' the parsing methods were assuming it would be formatted as the latter.

I've resolved the problem in this instance by explicitly specifying the InvariantCulture, as the data isn't displayed to the user. If it were intended for user display, then allowing the user's regional settings to influence the display would be quite appropriate.

FxCop (aka Visual Studio Code Analysis) will warn you about these kinds of issues, specifically CA1305 – Specify IFormatProvider. I've changed this warning (and a few others) to an error to ensure I don't get caught by it again.

Visual Studio Code Analysis Settings - changing warnings to errors

Expect Aussie Toilets v1.4 soon!

Sidenote

When I first started working on Aussie Toilets, I was doing it from the perspective of a parent who has had first-hand experience trying to find a public toilet for a young child. I hadn't really considered another market for the app might be the overseas visitor. Maybe I should consider providing translations for some of the labels for these users too.

No comments: