Why is InvalidEnumArgumentException obsolete in Silverlight 4?

I was surprised to discover that InvalidEnumArgumentException has been made obsolete in Silverlight 4.

Does anyone know why this is? I found this to be quite a useful exception, especially when manually deserialising binary data to enum values.

[ObsoleteAttribute(
  "InvalidEnumArgumentException is obs开发者_开发技巧olete. Use ArgumentException instead.")]
public class InvalidEnumArgumentException : Exception

You are right, it is marked obsolete but totally there (here is the correct link pointing to the Silverlight Version of the class)

I think this particular "Why" question is hard to answer for everyone here, who is not working at microsoft and involved in the process of reviewing such changes. There is probably some kind of document at Microsoft explaining the high-level reasons for marking it obsolete in the current version. It is as it is right now and i fear you might have to live with it.

Out of intereset i googled a bit with bing and this SO thread here was the best hit on the topic i could find. Even looking for it on Silverlight.net die not yield any results. So either you need a gold partner contract (or whatever its called) and contact the guys at Microsoft directly on the issue.

However there seems a bit controvery going on over this very same Exception, wether its good practice to use it or not, i would like to quote a comment on this link, talking about inconsistensies:

Unfortunately, as InvalidEnumArgumentException is defined in System.dll and not mscorlib.dll, the later does not throw it when an invalid enum argument is passed to a member, but instead throws ArgumentException or ArgumentOutOfRangeException. This inconsistancy however, usually does not present a problem, as this exception, when thrown, typically indicates a bug in the caller and is rarely caught within a catch clause.

So that might have also played into the whole circumstance that lead to removing it from Silverlight. Or not. Maybe its just because they thought its unneeded overhead, so to say, because you are probably catching ArgumentExceptions anyway and most implementatoins gain nothing by further breaking it down. Its just a guess, but i am afraid you wont get any better than this (besides other random guesses).

You could of course add your own InvalidEnumArgumentException implementation if you wanted to, and i would guess that you have already done so.