Solution to the "Localized exceptions" problem

[mlsomers]

The problem is well known and there are some workarounds available. Previous requests for a structural fix have not received much attention.

A preferred solution would be to have an app.config element (I suggest adding it to the runtime element) that would enable us to get non-localized messages in a specific deployment (e.g. on a developers machine).

Another approuch could be to add a new property to the Exception class called MessageNonLocalized (to keep it near Message in intellisense). Also update the ToString method to use that message instead of the localized one. (ToString() also adds the stacktrace, so this is for developers any way).

I know that we may be able to write extension methods or other workarounds, but jumping through a hoop whenever trying to debug some code can become tiresome, especially if it's not your own code or just an open source sidekick.

[CzBuCHi]

wut? i think i sah this type of request 8+ years ago .... and we still needs to translate exception messages to english?

PS: I personally DO NOT understand any of localized exception messages despite theyre written i my native language ...

PSS: At least give us identifier string, that is used as key in resx file, so we can google that instead of jiberish like "Tento typ CollectionView nepodporuje změny své kolekce SourceCollection z jiného než dispečerského vlákna." if english messages arent present on local machine...

[Hi-Angel]

I shall say, I don't use .NET much nowadays, but in case it's useful mono always does print english messages:

$ LANG=ru_RU.UTF-8 mono test.exe

Unhandled Exception:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
  at HelloWorld.Hello.Main () [0x00007] in <69eb3976d7534e8dae611f6b1ae97a34>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.IndexOutOfRangeException: Index was outside the bounds of the array.
  at HelloWorld.Hello.Main () [0x00007] in <69eb3976d7534e8dae611f6b1ae97a34>:0

I remember a year ago Mono wasn't, say, perfect, but it is sponsored by Microsoft, so hopefully it get (already got?) better.

[CzBuCHi]

yea ... IndexOutOfRangeException, NullReferenceException, KeyNotFoundException and maybe others arent translated at all ... but these dont even need message to figure out whats wrong.

BTW: at least for MsBuild-realted exceptions i managed to turn them to english by deleting all lang-related folders in c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\
with works until visual studio update, when installer downlaods these folders again ...

[artemious7]

@CzBuCHi

yea ... IndexOutOfRangeException, NullReferenceException, KeyNotFoundException and maybe others arent translated at all ... but these dont even need message to figure out whats wrong.

They DO need to be English. When I send my exceptions to Google Analytics (or other cloud service), I will have different groups of exceptions for the same exception, but different languages. And I will not be able to sort by count of each exception, because it doesn't reflect the real count (100 in English, 77 in Chinese, 80 in Korean... etc).
And figuring out each time which of the localized messages are which exceptions is a pain in the butt.

[richlander]

PTAL @terrajobst @tarekgh

[tarekgh]

In general, we don't recommend taking a dependency on the exception messages as these can change at any time even if they are English. Usually, we recommend depending on the exception itself and not the message. We have some cases (e.g. .Net Native) can optimize for the desk size and not include any exception messages.

It is not clear to me what exactly the scenario you are trying to make it work? why you want the messages in English while the user set their Language to something else?

I understand the debugging scenario, but this can be easily worked around by setting the UI culture to English as this will not affect the real user. and even if you have a localized message, you may use any machine translation to get the English translation. but I am not sure what exactly the other scenarios like what @artemious7 mentioned. what analysis needs to be done with the exception messages? and why?

[CzBuCHi]

only time our user actually see exception message is when that exception is unhandled, all other cases we showing our own message instead with context specific information (and hidden stack trace) with ability to send real exception message and stack trace via mail - and in that case non-english expection message is pain in the rear end because 99% of answers on internet about that exception are in english (and that 1% is about how to translate it to english)

[mlsomers]

@tarekgh the problem is not only for programmers who can indeed use a workaround (which is quite a hassle by the way). Administrators also heavily suffer from this. So much so that workarounds like http://www.unlocalize.com/ have been developed. When logging errors anywhere, the english version is much more desirable.

You say we should use the exception itself, well it can indeed be serialized, but then you need to make a tool that can un-serialize them again (and add all possible exception types must be declared beforehand in [XmlInclude(typeof(MySpecialException))] attributes for the collection containing them... totally unrealistic).

As I said before, I'd advocate for a new <runtime> sub-element in the app.config which we or any administartor can have control on how exceptions are rendered.

[tarekgh]

@CzBuCHi

only time our user actually see exception message is when that exception is unhandled, all other cases we showing our own message instead with context specific information (and hidden stack trace) with ability to send real exception message and stack trace via mail

Why don't you do the same for the unhandled exception as you are doing with the other exceptions? I mean you can subscribe to the unhandled exception event https://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(v=vs.110).aspx?

@mlsomers

You say we should use the exception itself, well it can indeed be serialized, but then you need to make a tool that can un-serialize them again (and add all possible exception types must be declared beforehand in [XmlInclude(typeof(MySpecialException))] attributes for the collection containing them... totally unrealistic).

you don't need to do that. you can just capture the exception class name and the stack and use them as strings so you can do whatever analysis you are doing today with the exception messages. I think this can give you more reliable way in the analysis than just the exception message.

As I said before, I'd advocate for a new sub-element in the app.config which we or any administartor can have control on how exceptions are rendered.

Exceptions take the message strings as a parameter. so you cannot control this for the exceptions only as you cannot guarantee the source of the message strings. And even if we have a way for the framework exceptions we'll not have a way for non-framework exceptions. To be able to have a uniform way to force the English language for getting the exception message is to force the whole app to use English UI culture which I believe the apps can do that as needed and the users can do that by running on English UI.

[CzBuCHi]

@tarekgh quick look at random framework code i see this:

throw new SerializationException(Environment.GetResourceString("Serialization_NoID"));

ony thing that i ask is that exception object will have extra property witch in this case will have value "Serialization_NoID" - that way when this exception occurs i can show user translated message and i can search for "SerializationException Serialization_NoID"

ofc this will work only in framework code ....

[tarekgh]

@CzBuCHi although Environment.GetResourceString is used mostly to get the exception message resources inside the core assembly (e.g. mscorlib.dll), Environment.GetResourceString is not restricted to the exception messages. it is used to get the resources in other scenarios. one example is here:

https://referencesource.microsoft.com/#mscorlib/system/globalization/culturedata.cs,1192

Also, in none-core assemblies Environment.GetResourceString is not used because it is internal to mscorlib. and instead, a direct instance of the ResourceManager is used to get the resources which is not restricted to exception messages too.

https://referencesource.microsoft.com/#System.Xml/System/Xml/Core/XmlReaderSettings.cs,382

[CzBuCHi]

@tarekgh What i mean is provide use some property that will identify that exception - dont care if it is key to resx or some crazy UINT64 value - only thing thas important thats this identifier would be unique and language independent and therefore easily searchable on forums ...

[tarekgh]

@CzBuCHi isn't the exception type and the stack can uniquely identify the exception?

[mlsomers]

@tarekgh you do have a point that the message is quite dynamic and you can't always have control, so that does complicate stuff I agree. Ironically that also means that the exception type and stack cannot specifically identify an exception.

An ArgumentException can be thrown for any of multiple arguments on a method, so the Message part is often essential. I personally often add some contextual info into the message, for example a I wrap a FileNotFound exception in order to specify the filename and path in the message (putting the original one in the InnerException).

Looks like we'll have to mess around with the workarounds then, but can't we at least have a standard workaround in the framework? An extension method on an exception that temporarily changes the thread Locale could kind-of work in my main projects. But when working on multiple projects for different customers or open source stuff, it's a real hassle to drag along a bag of code snippets. In 3rd party applications my hands are bound (unless I go down the decompiling and hacking route).

In my ideal world, administrators should also be able to temporarily change the thread locale when exceptions occur without having to depend on coders adding workarounds. It would enable them to solve many problems that now come my way because they do't have a clue, and neither does Bing.

[tarekgh]

An ArgumentException can be thrown for any of multiple arguments on a method, so the Message part is often essential.

Actually what is useful is the values inserted in the message. for example, in Argument exception, it is the argument name which you can still get it from the ParamName property from the exception object.

I am not pushing back on any idea here but I wanted to clarify that supporting English messages only wouldn't be trivial for the reasons I mentioned early, in addition, the admins would need to opt-in to whatever mechanism anyway. and if they do, they can force running on English cultures.

Does it help if provide a tool that can take the localized message and return the matched English text? I am just brainstorming the ways that may help. or having a spreadsheet have all messages in all supported languages for easier search?