2009-06-22 6 views
5

Imagine que tiene un método con la siguiente firma:Guid.Empty resultado en ArgumentException o ArgumentOutOfRangeException

public void DoSomething(Guid id) 

Si Guid.Emtpy representa un valor no válido, el tipo de excepción sería el más apropiado para tirar? ArgumentException o ArgumentOutOfRangeException?

Me estoy inclinando ligeramente hacia ArgumentException, ya que no creo que todos los GUID excepto Guid.Empty es mucho de un rango - es un poco demasiado inclusiva: Sólo hay un miembro excluido.

Sin embargo, de ninguna manera estoy decidido a que este sea el caso, entonces me gustaría saber si alguien puede presentar argumentos para una u otra.

Soy muy consciente de que esto es principalmente una discusión semántica, pero en interés del buen diseño de la API, me gustaría saber si hay casos claros para una u otra opción.

+0

Es casi como si su método necesita algún tipo de guía de buena guía. –

+0

¿Quizás defina su propia ArgumentEmptyException? – yfeldblum

+0

@Justice. No es aconsejable agregar un nuevo tipo de excepción para un escenario en el que nunca desea atraparlo. Mark debería arrojar uno de los tipos de excepción existentes. – Steven

Respuesta

5

Decir que un valor vacío está fuera de rango simplemente parece incorrecto. Como Guid.Empty se usa generalmente cuando no hay ningún valor definido, no hay realmente ningún valor que pueda estar fuera del rango.

La situación es similar a cuando usa ArgumentNullException, excepto que no hay una excepción específica para los valores vacíos. Una ArgumentNullException sería engañosa, por lo que ArgumentException se ajusta mejor.

Considere también si ApplicationException sería mejor. Eso se usa para excepciones en la aplicación en lugar de una biblioteca de clases.

+1

ApplicationException es un poco redundante y probablemente sea mejor evitarlo (http://stackoverflow.com/questions/52753/derive-from- exception-or-applicationexception-in-net). – adrianbanks

+0

@adrianbansk: Se trata de derivar de clases de excepción, que apenas se relaciona. Si no desea utilizar una excepción específica del sistema para que pueda atraparla junto con otras excepciones del sistema, una ApplicationException funciona bien. – Guffa

+1

Sí, lo sé. A lo que me refería es que si muchos consideran que ApplicationException "no debería ser parte del .Net Framework", su uso puede quedar obsoleto en el futuro. Evitar su uso ahora para una ArgumentException más relevante evitaría este problema más adelante. – adrianbanks

1

Tire un Invalid ArgumentException. Eso sigue exactamente la semántica que buscas. No arrojaría un ArgumentOutOfRangeException si espera un uint y todos los valores excepto 0xffffffff son válidos, ¿verdad?

+3

InvalidArgumentException es parte del espacio de nombres Microsoft.SqlServer.Management.Common. No querrá agregar una referencia solo para obtener acceso a esa excepción. Use ArgumentException en su lugar, que está en el espacio de nombres del sistema. – Guffa

+0

Tienes toda la razón. Podría haber jurado que vi una excepción InvalidArgumentException en código BCL directo, ya que nunca utilicé SqlServer ... – OregonGhost

7

Yo arrojaría un ArgumentException. Es docs decir:

La excepción que se produce cuando uno de los argumentos proporcionados a un método no es válido.

que es exactamente el caso que usted describe. Desea algo similar a:

throw new ArgumentException("Guid.Empty is not a valid id", "id");
0

AE.

Exactamente, ¿cuál es el rango aceptable de Guids que su método está esperando?

¿CA72EE5A-5F26-11DE-BD28-13A156D89593 está dentro del rango aceptable, pero D58B3112-5F26-11DE-B0D2-5FA156D89593 está fuera?

+0

Creo que el rango aceptable es 00000000-0000-0000-0000-000000000001 a FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF. Por lo tanto, creo que podemos concluir que Mark debe arrojar una ArgumentOutOfRangeException, porque solo hay un valor único que no es válido. Debería lanzar InvalidSingleArgumentValueException, pero como esta excepción no existe, me gustaría ir a ArgumentException :-) – Steven

Cuestiones relacionadas