Mejores prácticas al informar mensajes de excepción al usuario

Question

En mi aplicación ASP.NET MVC, no deseo informar todos los mensajes de excepción al usuario. Pero hay ciertos tipos de excepciones que me gustaría informar al usuario, por lo que creé un filtro de acción para decidir si se trata de este tipo particular de excepción, y si es así, mostrar el mensaje de la excepción; de lo contrario, mostrar un mensaje genérico. Así que creé una excepción personalizada llamada ClientException.

Mi filtro es como la siguiente:

if (filterContext.Exception is ClientException) 
     message = filterContext.Exception.Message.Replace("\r", " ").Replace("\n", " "); 
    else 
     message = "An error occured while attemting to perform the last action. Sorry for the inconvenience."; 

    filterContext.HttpContext.Response.Status = "500 " + message; 

leí este http://blogs.msdn.com/b/kcwalina/archive/2007/01/30/exceptionhierarchies.aspx donde el autor recomienda el uso de tipos de excepción .NET existentes para informar de errores de uso. Sin embargo, al presentar mi excepción personalizada, solo tengo que hacer una única comprobación en mi filtro. ¿Está mi enfoque bien?

Answer 1

Me gusta este enfoque por un par de razones.

En primer lugar, falla de forma segura. Si alguien no explicita lanza una excepción de cliente, entonces los detalles de la excepción no se informan. Olvidarse de mostrar algo es un problema menor que mostrar accidentalmente algo.

En segundo lugar, permite la decisión sobre si se debe mostrar la excepción en el lugar correcto. No todas las IOExcepciones se muestran, por ejemplo. Algunos pueden ser y otros no. Las excepciones específicas se pueden capturar y transformar en cualquier lugar de la pila de llamadas, de modo que la transformación se pueda realizar en un lugar donde se sepa que es correcta.

Ambas cosas en conjunto significan que un futuro desarrollador no cambiará indebidamente toda una clase de excepción para mostrar, o pensará que algo no se mostrará cuando realmente será.

Además, el propósito de utilizar un tipo de excepción en particular es determinar más adelante qué acción tomar en respuesta a esa excepción. "Mostrar este mensaje al usuario" es una acción perfectamente buena para especificar. Una vez que se ha tomado esa decisión, entonces la naturaleza exacta de la excepción es completamente irrelivante. (El problema original se puede poner en la propiedad InnerException, para fines de registro, por supuesto.)

Por lo tanto, en mi opinión, este es un buen diseño.

Answer 2

Si su enfoque funciona para usted, entonces está bien. ¿Y te sorprende que un blog de Microsoft recomiende que uses su clase Exception? ;)

Hay algunas características de la biblioteca .NET y cosas de OSS de terceros que solo funcionarán con las excepciones de .NET.

Para obtener lo mejor de ambos mundos, siempre podría extender el objeto Excepción de .NET al suyo.

Answer 3

Usaría diferentes valores de umbral en función del tipo de excepciones, y estos valores de umbral se asociarían con los mensajes de excepción.

En función de la lógica del valor de Umbral particular, es posible que desee decidir si se muestra o no la excepción.

Answer 4

Su enfoque es excelente IMO, pero hay alternativas. (Somos desarrolladores de software, de modo que siempre hay alternativas.)

Usted podría aprovechar el diccionario Exception Data para almacenar una bandera que indica si existe o no una excepción es una excepción cliente. Entonces podría hacer que su filtro verifique la existencia de la bandera.

Answer 5

mis preocupaciones con esta solución es que es muy probable estas excepciones típicamente serán arrojados por los objetos de una capa de negocio (o los objetos del modelo en la terminología MVC). El uso que describes es realmente lo que consideraría una preocupación de presentación.

lo general que había necesidad de volver a lanzar cualquier excepción que tiene en su modelo, sólo se comunica a si o no la excepción puede ser expuesto al usuario o no. ¿Qué espera el usuario a hacer con la información? Si el usuario puede arreglar la situación tal vez no debería ser una excepción para indicar el estado para empezar?

que se pegaba a la captura de excepciones específicas por caso y hacer decisiones de presentación en el lugar. Sin embargo, puede enviar una excepción, como capturada, como modelo a una vista. Todavía dejaría que el controlador decida, no quien arroje la excepción.