Throwing a general exception type such as Exception or SystemException in a library or Framework forces consumers to catch all exceptions, including unknown exceptions that they do not know how to handle.
Instead, either throw a more derived type that already exists in the Framework, or create your own type that derives from Exception.
The following list examples of when you should throw specific exceptions:
When validating a parameter (including the value parameter in the set accessor of a property) that:
- Is a null reference ( Nothing in Visual Basic)
throw System.ArgumentNullException - Is outside of the allowable range of values (such as an index for a Collection/List)
throw System.ArgumentOutOfRangeException - Is an invalid enum value
throw System.ComponentModel.InvalidEnumArgumentException - Contains a format that not meet the parameter specifications of a method (such as the format string for ToString(String))
throw System.FormatException - Is otherwise invalid
throw System.ArgumentException
When an operation is invalid for an object's current state:
throw System.InvalidOperationException
When an operation is performed on an object that has been disposed:
throw System.ObjectDisposedException
When an operation is not supported (such as in an overridden Stream.Write in a Stream opened for reading):
throw System.NotSupportedException
When a conversion would result in an overflow (such as in a explicit cast operator overload):
throw System.OverflowException
For all other situations, consider creating your own type that derives from Exception and throw that. For more information, see Krzysztof Cwalina's blog How to Design Exception Hierarchies (http://blogs.msdn.com/kcwalina/archive/2007/01/30/ExceptionHierarchies.aspx)