Qué tipo de excepción arrojar para las cadenas

Question

Si tengo lo siguiente, realmente para cualquier cadena donde marque IsNullOrEmpty y aparezca vacía, qué tipo de tipo de excepción debería arrojarse, y no es un argumento para un método?

Siempre me cuesta seleccionar tipos de excepción porque hay tantos malditos. Y esto solo está tomando un valor del web.config y comprobando si SandboxSoapApiUsername volvió vacío.

if(string.IsNullOrEmpty(ConfigUtility.SandboxSoapApiUsername)) 
     throw new WTF do I throw here??? ahhh 

Probablemente depende del uso/contexto correcto? Bueno, usaré la cadena devuelta para establecer un campo privado de clase. Así que necesito verificar si es una cadena vacía al principio del proceso en vez de más tarde (en lugar de depender de otro código para verificar la propiedad relacionada con el campo privado al que voy a configurar ConfigUtility.SandboxSoapApiUsername).

Dado que las propiedades de esta clase a las que estoy configurando cada ConfigUtility.MEthodName se usarán en una solicitud SOAP, pensé que tal vez UriFormatException sería apropiado aquí aunque este no sea el Uri?

Answer 1

Depende de cuándo proviene la secuencia. Un argumento podría causar una ArgumentNullException. La configuración puede arrojar una ConfigurationException (que parece ser aplicable a este caso). O puede, por supuesto, crear el suyo de todos modos.

Answer 2

Si se pasó como argumento, tira ArgumentNullException.

De lo contrario, realmente depende de qué significa la cadena null en el contexto de su aplicación. No tenga miedo de definir tipos de excepción personalizados si no hay algo en el marco base para el escenario.

Answer 3

Los métodos en .NET Framework generalmente distinguen entre null y un valor no válido pasado para un argumento. Creo que debería lanzar un Argumento ​ Null ​ Excepción si el valor es nulo y un Argumento ​ Excepción si no es válido.

if (arg == null) 
    throw new ArgumentNullException("arg", "argcannot be null"); 
if (arg == string.Empty) 
    throw new ArgumentException("arg cannot be an empty string", "arg"); 

Si el valor no es un argumento, pero, por ejemplo, cargada durante la inicialización, creo que un inválido ​ Operación ​ excepción sería apropiado:

if (string.IsNullOrEmpty(ConfigUtility.SandboxSoapApiUsername)) 
    throw new InvalidOperationException("Cannot initialize because " + 
             "SandboxSoapApiUsername not configured"); 

Answer 4

que necesita una excepción InvalidConfiguration - definir uno

throw new InvalidConfigurationException("Must supply user name") 

Answer 5

Puesto que parece que algo no se ha configurado correctamente, sugeriría System.Configuration.ConfigurationErrorsException.

Nota: no use System.Configuration.ConfigurationException. Es una versión anterior y ha quedado obsoleta.

Nota 2: Aunque estoy 90% seguro que estamos tratando con un valor de configuración faltante, si se trata de un parámetro de método que le falta, lanzar una ArgumentException o ArgumentOutOfRangeException.

Answer 6

Realmente pasará la mayor parte de su tiempo eligiendo de la lista a continuación al lanzar una excepción new (en lugar de simplemente hacer un throw).

1. ConfigurationException
   • La excepción que se produce cuando se ha producido un error del sistema de configuración.
2. ArgumentException
   • La excepción que se produce cuando uno de los argumentos proporcionados a un método no es válido.
3. InvalidOperationException
   • La excepción que se produce cuando una llamada al método no es válido para el estado actual del objeto.

1)
Esto podría decirse que no tiene sentido a menos que usted está recogiendo el ajuste de un app.config o web.config:

La excepción ConfigurationException si se lanza la aplicación intenta para leer o escribir datos en el archivo de configuración , pero es sin éxito. Algunos posibles motivos para esto pueden incluir XML con formato incorrecto en el archivo de configuración, archivos de problemas de permisos y propiedades de configuración con valores que no son válidos.

2)
No es un argumento así que éste no tiene mucho sentido.

3)
Este es el mejor de los tres ya que el objeto estará en un estado inválido. Sin embargo, dependiendo de qué tan grande sea su conjunto de configuraciones, preferiría hacer mi propia excepción derivada de System.Exception.

Hay dos escuelas de pensamiento de las cuales derivar - System.Exception y ApplicationException *. Dos desarrolladores diferentes en el equipo del framework han expresado diferentes puntos de vista de los cuales creen que debes heredar, me quedo con Jeffrey Richter's view.

Si todo lo anterior suena como woffle, entonces puede elegir uno que considere más relevante de the list.

^{* Parece que MSDN ahora está de acuerdo con sus desarrolladores marco que ApplicationException fue un error de diseño}