¿Hay alguna razón para NO usar clases de excepción definidas por .NET Framework en su propio código?

Question

Por lo tanto, estamos utilizando el Enterprise Library 4.1 Exception Handling Application Block para gestionar el registro y el manejo de nuestras excepciones en una aplicación de proyectos múltiples. Tenemos algunas excepciones personalizadas y estamos lanzando algunas excepciones cuyas clases están definidas en las bibliotecas de clases estándar de .NET Framework (por ejemplo, ArgumentException, InvalidOperationException, ArgumentNullException, etc.).

Hoy, nuestro jefe de equipo decidió que no quería que utilizáramos este último, ya que .NET framework lanzaría esos tipos de excepciones, y para facilitar el filtrado con las políticas del bloque de aplicaciones, deberíamos usar solo excepciones personalizadas, yendo tan lejos como para duplicar prácticamente excepciones biblioteca de clases .NET estándar con versiones personalizadas, como en personalizada ArgumentException, personalizada InvalidOperationException, etc.

Mi pregunta es, cuál es el problema con este enfoque? No pude entenderlo en ese momento, pero me olía mal y no he podido sacudir mis intranquilos sentimientos al respecto. ¿Estoy preocupado por algo que realmente no es tan importante? Supongo que parece que la cola mueve al perro un poco aquí ...

Answer 1

Ick. Lo que no me gusta de ella es:

• Se duplica tipos existentes
• Viola el principio de la menor sorpresa
• Esto significa que si usted quiere encontrar en todas partes que usted ha utilizado el valor del argumento equivocado (por ejemplo) debe buscar dos tipos de jerarquías de excepción en lugar de simplemente buscar ArgumentException.

Le sugiero que obtenga el plomo de su equipo para leer el elemento 60 de Effective Java 2nd edition. Sí, se trata de Java en lugar de C#, pero los principios siguen siendo los mismos.

Answer 2

Bueno, las excepciones arrojadas por tu código y arrojadas por las clases base de .net deben manejarse de la misma manera.

Ambos son probablemente el síntoma de un problema en su código, por lo que ninguno debe ignorarse ni filtrarse.

Answer 3

El libro Framework Design Guidelines (primera edición) de Krzysztof Cwalina y Brad Abrams recomienda tirar las excepciones existentes definidas en los espacios de nombres System donde se pueda, y cuanto más específico, mejor. Si no hay un buen ajuste, ejecute una excepción personalizada.

Creación de un universo paralelo de encargo ArgumentNullException para que coincida con System.ArgumentNullException es una duplicación de esfuerzos que no veo ningún valor. Al final del día, si su código lanza una System.ArgumentNullException en lugar de una clase de marco que pueda determinar a partir del seguimiento de la pila quién fue el responsable final.

Esto huele a trabajo adicional innecesario para el presente y el futuro en lo que respecta al tiempo de mantenimiento del código.

Answer 4

Lanzar excepciones .Net está bien cuando la excepción describe correctamente el tipo de problema que intentas exponer (por ejemplo, cuando un argumento es nulo, debes lanzar una ArgumentNullException). Si encuentra una situación que no es manejada por .Net Framework (por ejemplo, si desea dividir 6 por 3, pero eso no está permitido por su aplicación) debe crear una excepción personalizada.

Answer 5

Me hago eco de las respuestas de Jon Skeet y Kev. Solo agregaría que si su política de excepción desea tratar excepciones de nivel de marco diferentes a sus propias excepciones, considere usar el rastreo de la pila de la excepción.