runtime: When does core clr throw CultureNotSupported exception?

On windows, new CultureInfo("zh-CHS") or new CultureInfo("Shared") (bogus name) throw a CultureNotFoundException. On OSX they don’t. However, “zh-CHS” was obtained by calling CultureInfo.GetCultures(CultureTypes.AllCultures) on full framework. reading dotnet/runtime#14558 I get the understanding that any string is now fair game and should be supported.

In light of this, when can one expect CultureNotFoundException and why is zh-CHS not recognized on windows, when the full framework API returns it as supported?

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 1
Comments: 16 (12 by maintainers)

Most upvoted comments

If you don’t agree that only retrieving predefined cultures should be CultureInfo.GetCultureInfo()’ s default behavior - or if changing this now is not an option for the sake of backward compatibility, do you see that the behavior described would be a useful addition, notably to guard against typos?

That is not the scenario that concern. because people usually don’t type the culture manually (except in code which they need to test anyway).

I think this need to be discussed with the Windows team who decided to have this behavior. as I mentioned, the framework has to follow the OS or otherwise, we’ll end up special casing a lot of stuff for every OS.

From your side, you still have a way to filter the fake cultures by getting the EnglishName which will start with text Unknown Locale

new CultureInfo("ff-dd").EnglishName

will produce

Unknown Locale (ff-DD)

tarekgh on Sep 6, 2018

@tarekgh Thanks! Now I was able to create a test with CultureNotFoundException for Get-Cuture cmdlet.

I also agree with @mklement0 that this behavior is somewhat different for different platforms and this can surprise users. At least it’s hard to write code with predictable behavior for all platforms that are expected from .Net Core.

iSazonov on Sep 6, 2018