Código de error/Gestión de mensajes en .NET

Question

en busca de sugerencias/mejores prácticas en la gestión de los códigos de error y mensajes en unas aplicaciones de varios niveles. Específicamente cosas como:

1. ¿Dónde deberían definirse los códigos de error? Enum? ¿Clase?
2. ¿Cómo se asocian los mensajes de error o los detalles adicionales con los códigos de error? archivos de recursos? atributos en valores enum, etc.?
3. Si tiene una aplicación de varios niveles que consta de DAL, BLL, UI y proyectos comunes, por ejemplo, ¿debería haber una única lista gigante de códigos para todos los niveles, o los códigos son extensibles por proyecto/nivel?

Actualización: importante mencionar que no puede basarse únicamente en las excepciones y tipos de excepción personalizada para el informe de errores, ya que algunos clientes para esta aplicación serán través de servicios web (SOAP) & RESTO

Cualquier sugerencia bienvenida!

Answer 1

Creo que es mejor crear un proyecto común (o Proyecto marco de aplicaciones) y poner los excepciones y Common Object en él.

Siempre es una buena idea tener un marco de aplicaciones que contiene Clase base para sus clases (especialmente en la interfaz de usuario - PageBase - MasterBase- ModuleBase y etc)

Y como es obvio que tiene que poner sus clases y Enum en su proyecto BLL.

Tenga en cuenta que 3 niveles no significa 3 Proyecto. Puede tener 5 proyectos en su BLL.

Por último, no olvide utilizar ELMAH o cualquier otra herramienta similar.

Answer 2

Los códigos de error son viejos, los necesitabas en los malos tiempos de la programación COM y C, entornos que no admitían excepciones. En la actualidad, utiliza excepciones para notificar al código del cliente o al usuario sobre problemas. Las excepciones en .NET son autodescriptivas, tienen un tipo, un mensaje y diagnósticos.

Necesita distinguir dos tipos de excepciones, aquellas que son razonablemente recuperables y aquellas en las que no tiene idea de qué fue exactamente lo que salió mal o cómo se recupera de ellas. El último tipo es con mucho el más común, necesitará un ser humano para tomar medidas correctivas. Use uno de los tipos de excepción .NET incorporados estándar para subirlos. IllegalOperationException, FormatException, ArgumentException son opciones comunes. Si es el back-end el que plantea una excepción de este tipo, solo quiere pasarla sin alterarla. Por lo general, necesita un bloque finally para garantizar que su estado interno sea coherente, a veces un bloque catch que contenga un simple lanzamiento para recuperar el estado.

Todo lo que considere recuperable debe plantearse con un tipo de excepción que usted mismo declare, derivado de la clase Excepción. Eso le da al código aguas arriba la oportunidad de escribir una cláusula catch y hacer algo significativo. Necesitará generar un mensaje que sea descriptivo del problema, en caso de que el código de flujo ascendente no lo maneje realmente, el texto del mensaje debe ser recuperado de una cadena codificada o un recurso si localización de soporte.