Mejores prácticas para crear un patrón de códigos de error para un proyecto empresarial en C # [cerrado]

Hay una diferencia entre los códigos de error y los valores de retorno de error. Un código de error es para el usuario y la mesa de ayuda. Un valor de retorno de error es una técnica de codificación para indicar que su código ha encontrado un error.

Uno puede implementar códigos de error usando valores de retorno de error, pero yo recomendaría eso. Las excepciones son la forma moderna de informar errores, y no hay ninguna razón por la que no deban llevar un código de error dentro de ellos.

Así es como lo organizaría (tenga en cuenta que los puntos 2-6 son independientes del idioma):

1. Use un tipo de excepción personalizado con una propiedad adicional ErrorCode . La captura en el bucle principal informará este campo de la forma habitual (archivo de registro / ventana emergente de error / respuesta de error). Use el mismo tipo de excepción en todo su código.
2. No comience en 1 y no use ceros iniciales. Mantenga todos los códigos de error a la misma longitud, por lo que es fácil detectar un código de error incorrecto. A partir de 1000 por lo general es lo suficientemente bueno. Tal vez agregue una 'E' inicial para que sean claramente identificables para los usuarios (especialmente útil cuando la mesa de soporte tiene que indicar a los usuarios cómo detectar el código de error).
3. Mantenga una lista de todos los códigos de error, pero no haga esto en su código . Mantenga una lista corta en una página wiki para desarrolladores, que pueden editar fácilmente cuando necesiten un nuevo código. La mesa de ayuda debe tener una lista separada en su propia wiki.
4. No intente imponer una estructura en los códigos de error. Siempre habrá errores difíciles de clasificar y no querrá discutir durante horas si un error debe estar en el grupo 45xx o en el grupo 54xx. Sea pragmático .
5. Asigna a cada lanzamiento en tu código un código separado. Aunque piense que es la misma causa, es posible que la mesa de ayuda necesite hacer cosas diferentes en diferentes casos. Es más fácil para ellos tener "E1234: ver E1235" en su wiki, que hacer que el usuario confiese lo que ha hecho mal.
6. Dividir los códigos de error si el servicio de asistencia lo solicita. Una simple línea if (...) throw new FooException(1234, ".."); else throw new FooException(1235, ".."); en su código podría ahorrarle media hora a la mesa de ayuda.

Y nunca olvide que el propósito de los códigos de error es hacer la vida más fácil para el servicio de asistencia .

Primero debe aislar las áreas donde pueden ocurrir errores, y son visibles para el usuario. Luego puedes documentarlos. Es así de simple.

Bueno, simple en teoría ... en la práctica, los errores pueden ocurrir en todo el maldito lugar, y reportarlos puede convertir un buen código en un monstruo de registro, lanzamiento y manejo de excepciones, y pasar valores de retorno.

Recomendaría un enfoque de 2 pasos entonces. Lo primero es registrar, registrar lotes y lotes.

Lo segundo es determinar los componentes principales y sus interfaces, y definir en qué casos de error mayor se pueden encontrar estos componentes. Luego, puede iniciar sesión de una manera más visible cuando uno de estos errores (cómo se maneja el error internamente es Depende de usted: las excepciones o los códigos de error no hacen ninguna diferencia aquí). Por lo general, un usuario verá el error e irá a los registros para obtener información más detallada.

El mismo enfoque se utiliza para servidores web y su ejemplo de código de error http. Si el usuario ve un 404 e informa que es compatible, buscará en los registros los detalles de lo que estaba sucediendo, la página que visitó, cuándo y recopilará cualquier otra información que pueda de cualquier otro lugar que tenga sentido. , estar en la base de datos, la red o la aplicación.

Iría por excepciones personalizadas con nombres descriptivos y mensajes claros y los emitiría. Es mucho más fácil usar la infraestructura de excepción existente de un lenguaje que construir soporte para pasar códigos de error e interpretarlos.