An interesting thread on the API Design Hall of Shame on Brad Abrams' blog.

I have a question, how was the decision for these 2 classes ctor parameters made...

Constructor for ArgumentNullException

public ArgumentNullException( string paramName, string message)

 

Constructor for ArgumentException

public ArgumentException( string message, string paramName)

 

Well, in short Jeff, this was a design mistake.  In fact it is up on the internal “API Design Hall of Shame”.  Here is the text from that site:

 

ArgumentNullException does not follow the constructor pattern given in the Design Guidelines spec.
Result: Habit wins out and people commonly type:
throw new ArgumentNullException (“must pass an employee name”);
rather than:
throw new ArgumentNullException (“Name”, “must pass an employee name”);
so we end up with error message such as:
Unhandled Exception: System.ArgumentNullException: Value cannot be null. Parameter name: must pass employee name
Lesson: Just follow the pattern!

 

Got any other examples that should be in my API Design Hall of Shame?

 

Even more interesting are the comments to this post, where Dwayne points out:

There is no base data access exception for the data access libraries. For example, the System.Data.SqlClient.SqlException derives from System.SystemException. So does the System.Data.OracleClient.OracleException class. This makes it more difficult to create a common data access interface that uses these classes internally but throws an implementation agnostic exception. It would have been nice if they had a System.Data.DataException that these exceptions derived from, so that my interfaces could be consistent.

Great point.  It would be convenient to have a System.Data.DataException, where each provider extends from that base type.  Instead, you have two choices:  explicitly filter for each provider that your layer supports, or catch System.SystemException... which is still not optimal.  However, this is leaps and bounds better than VB's prior “On Error“ statement, where you were to explictly check for the error number in an active error label.  Exceptions based on rich type information are a big win for the .NET framework.

Atif then follows up on the Exceptions hierarchy with:

I get the impression that the various teams could not always agree on the best place to branch off their exception hierarchy. For example, some exceptions from the framework are based off ApplicationException.

This is actually noted in Chapter 7 (IIRC) of Richter's book, that there is inconsistency in the framework itself on the appropriate use of ApplicationException and SystemException.  He notes that SystemException intends to capture all of the exceptions relating to the framework, but this guideline was not consistently followed.  The general guidelines should be:

• If you have a procedure that checks arguments and throws exceptions if the arguments are null or out of range, by all means use the ArgumentOutOfRangeException and ArgumentNullException (noting the parameter order shift explained above).  Using a custom exception provides no extra information.
• If your method is created to open a file, then throw a System.IO exception.  The user should expect an IO exception possibility when they are asking to work with a file.
• If your method is supposed to provide information from the database and employs a caching scheme for a local file, exposing a System.IO exception makes little sense because the consumer has no concept that there is a file involved... they were asking for something from the database.  In this case, throw a custom exception derived from ApplicationException, and in its constructor, provide the InnerException argument containing the System.IO.Exception.  The informaiton is preserved and much more meaningful to the consumer of your method.