Qué excepciones se deben lanzar para parámetros no válidos o inesperados in.NET?

He votado por La respuesta de Josh , pero me gustaría añadir una más a la lista:

Sistema.InvalidOperationException debe ser lanzado si el argumento es válido, pero el objeto está en un estado donde el argumento no debe ser usado.

Actualización Tomada de MSDN:

InvalidOperationException se utiliza en casos en que la omisión de invocar un el método es causado por razones distintas a argumentos no válidos.

Digamos que su objeto tiene un Método PerformAction (enmSomeAction action), las enmSomeActions válidas están Abiertas y Cerradas. Si llama a PerformAction (enmSomeAction.Abrir) dos veces seguidas, entonces la segunda llamada debería lanzar la InvalidOperationException (ya que la anulación era válida, pero no para el estado actual del control)

Dado que ya estás haciendo lo correcto programando defensivamente, tengo otra excepción que mencionar es ObjectDisposedException. Si su objeto implementa IDisposable, a continuación, usted siempre debe tener una variable de clase que rastree el estado dispuesto; si su objeto ha sido dispuesto y un método es llamado sobre él, debe levantar la ObjectDisposedException:

public void SomeMethod()
{
    If (m_Disposed) {
          throw new ObjectDisposedException("Object has been disposed")
     }
    // ... Normal execution code
}

Actualización: Para responder a su seguimiento: Es una situación un poco ambigua, y se hace un poco más complicada por un tipo de datos genérico (no en el sentido genérico de. NET) que se utiliza para representar un conjunto específico de datos; una enumeración u otro objeto fuertemente tipeado sería un ajuste más ideal--pero no siempre ten ese control.

Personalmente me inclinaría hacia la excepción ArgumentOutOfRangeException y proporcionaría un mensaje que indica que los valores válidos son 1-12. Mi razonamiento es que cuando se habla de meses, suponiendo que todas las representaciones enteras de meses son válidas, entonces se espera un valor en el rango de 1-12. Si solo ciertos meses (como los meses que tenían 31 días) fueran válidos, entonces no se trataría de un Rango per-se y yo lanzaría una excepción genérica ArgumentException que indicó los valores válidos, y también los documentaría en los comentarios del método.

Dependiendo del valor real y qué excepción se ajusta mejor:

• ArgumentException (algo está mal con el valor)

• ArgumentNullException (el argumento es nulo, mientras que esto no está permitido)

• ArgumentOutOfRangeException (el argumento tiene un valor fuera del rango válido)

Si esto no es lo suficientemente preciso, simplemente derive su propia clase de excepción de ArgumentException.

La respuesta de Yooder me iluminó. Una entrada es no válidosi no es válido en ningún momento, mientras que una entrada es inesperada si no es válida para el estado actual del sistema. Así que en el caso posteriorInvalidOperationException es una elección razonable.

Excepción de argumento.

• Sistema.ArgumentException
• Sistema.ArgumentNullException
• Sistema.ArgumentOutOfRangeException

ArgumentException :

ArgumentException se lanza cuando un método se invoca y al menos uno de los argumentos pasados no cumplen con el parámetro especificación de la llamada método. Todas las instancias de ArgumentException debe llevar un mensaje de error significativo que describe el argumento inválido, así como la rango esperado de valores para el argumento.

Existen también algunas subclases para tipos específicos de invalidez. El enlace tiene resúmenes de los subtipos y cuándo deben aplicarse.

Respuesta Corta:
[5]]}

Respuesta más larga:
usar el argumento * Exception (excepto en una biblioteca que es un producto en su on, como la biblioteca de componentes)es un olor. Las excepciones son para manejar situaciones excepcionales, no errores, y no las deficiencias del usuario (es decir, del consumidor de API).

Respuesta más larga:
Lanzar excepciones para argumentos no válidos es grosero, a menos que escriba una biblioteca.
Prefiero usar aserciones, por dos (o más) razones:

• Las afirmaciones no necesitan ser probadas, mientras que las aserciones de tiro hacen, y la prueba contra ArgumentNullException se ve ridículo (pruébalo).
• Las afirmaciones comunican mejor el uso previsto de la unidad, y es más cerca de ser ejecutable documentación que un comportamiento de clase especificación.
• Puede cambiar el comportamiento de violación de aserción. Por ejemplo, en la compilación de depuración, un cuadro de mensaje está bien, por lo que su QA lo golpeará de inmediato (también obtendrá su IDE romper en la línea donde sucede), mientras que en la prueba unitaria puede indicar un error de aserción como un error de prueba.

Aquí es cómo se ve el manejo de la excepción nula (siendo sarcástico, obviamente):

try {
    library.Method(null);
}
catch (ArgumentNullException e) {
    // retry with real argument this time
    library.Method(realArgument);
}

Se utilizarán excepciones cuando se espera una situación pero excepcional (suceden cosas que están fuera del control del consumidor, como la falla de IO). Argumento * Excepción es una indicación de un error y debe ser (mi opinión) manejado con pruebas y asistido con Depurar.Assert

Por cierto: En este caso en particular, podría haber utilizado Month type, en lugar de int. C# se queda corto cuando se trata de seguridad de tipo (Aspecto# rulez!) pero a veces se puede prevenir (o atrapar en tiempo de compilación) esos errores todos juntos.

Y sí, MicroSoft se equivoca al respecto.

Hay una excepción ArgumentException estándar que puedes usar, o puedes subclase y hacer la tuya propia. Hay varias clases específicas de ArgumentException:

Http://msdn.microsoft.com/en-us/library/system.argumentexception (VS.71).aspx

El que funcione mejor.