remarks para cref c# .net exception exception-handling

c# - cref - ¿Para qué sirve ApplicationException en.NET?



remarks c# (3)

De acuerdo con los remarks en msdn:

Las aplicaciones de usuario, no el tiempo de ejecución de lenguaje común, arrojan excepciones personalizadas derivadas de la clase ApplicationException. La clase ApplicationException diferencia entre las excepciones definidas por las aplicaciones frente a las excepciones definidas por el sistema.

Si está diseñando una aplicación que necesita crear sus propias excepciones, se le recomienda derivar excepciones personalizadas de la clase Excepción. Originalmente se pensó que las excepciones personalizadas deberían derivar de la clase ApplicationException; sin embargo, en la práctica esto no se ha encontrado para agregar un valor significativo. Para obtener más información, vea las Mejores prácticas para manejar excepciones.

Derrútalos de Exception . Además, no veo ningún problema para crear nuevas excepciones para sus casos, siempre que esté justificado. Si se encuentra con un caso en el que ya existe una excepción en el marco, úselo, de lo contrario, ejecute el suyo.

Para lanzar excepciones, generalmente utilizo las clases de excepciones integradas, por ejemplo, ArgumentNullException y NotSupportedException . Sin embargo, a veces necesito usar una excepción personalizada y en ese caso escribo:

class SlippedOnABananaException : Exception { } class ChokedOnAnAppleException : Exception { }

y así. Luego tiro y atrapo estos en mi código. Pero hoy encontré la clase ApplicationException , ¿debería usar eso en su lugar? ¿Para qué es esto?

Parece ineficiente tener muchas clases de Excepción efectivamente idénticas con diferentes nombres (generalmente no necesito ninguna funcionalidad individual). Pero no me gusta la idea de atrapar una ApplicationException genérica y tener que usar código adicional para determinar cuál fue el error.

¿Dónde debería encajar ApplicationException con mi código?


En el diseño inicial, en .NET 1.0, se planificó que el marco en sí lanzará SystemException y se derivará; mientras que las aplicaciones de usuario lanzarán ApplicationException y derivadas.

Pero más tarde, en .NET 2.0, se eliminó.

Por lo tanto, deriva de Exception .


La respuesta corta es: en ninguna parte.

Es una reliquia del pasado, donde Microsoft pretendía que los desarrolladores heredasen todas sus excepciones personalizadas de ApplicationException. Poco después, cambiaron de opinión y aconsejaron que las excepciones personalizadas deberían derivar de la clase de excepción base. Consulte las mejores prácticas para manejar excepciones en MSDN.

Una de las razones más ampliamente difundidas para esto proviene de un comentario de Jeffery Richter en las Pautas de diseño del marco :

System.ApplicationException es una clase que no debe ser parte de .NET Framework. La idea original era que las clases derivadas de SystemException indicarían excepciones lanzadas desde el CLR (o sistema) en sí, mientras que las excepciones que no son CLR se derivarían de ApplicationException . Sin embargo, muchas clases de excepción no siguieron este patrón. Por ejemplo, TargetInvocationException (que se lanza por el CLR) se deriva de ApplicationException . Entonces, la clase ApplicationException perdió todo el significado. La razón para derivar de esta clase base es permitir que algún código más arriba en la pila de llamadas capture la clase base. Ya no era posible detectar todas las excepciones de la aplicación.

Entonces ahí lo tienes. El resumen ejecutivo es que ApplicationException no es dañino , solo inútil .