studio - returns c#
¿Cuándo es apropiado usar códigos de error? (10)
C #, y probablemente Java también, admite un mejor flujo de control de manejo de excepciones, la palabra clave finalmente, que hace las cosas un poco más agradables que el uso de códigos de error. Un objeto de excepción puede contener cualquier nivel de detalle, ciertamente mucho más que un código de error. Por lo tanto, el objeto de excepción es mucho más práctico, pero podría encontrarse con un caso poco común en el que un código de error sería más apropiado.
FWIW, C ++ también admite objetos de excepción. No creo que C ++ sea compatible con una palabra clave finalmente (aunque es posible que los usuarios más nuevos de C ++ puedan hacerlo), pero en C ++ también debes evitar cosas como regresar dentro de un controlador de captura.
En lenguajes que admiten objetos de excepción (Java, C #), ¿cuándo es apropiado usar códigos de error ? ¿Es apropiado el uso de códigos de error en aplicaciones empresariales típicas?
Muchos sistemas de software conocidos emplean códigos de error (y una referencia de código de error correspondiente). Algunos ejemplos incluyen sistemas operativos (Windows), bases de datos (Oracle, DB2) y productos de software intermedio (WebLogic, WebSphere). ¿Qué beneficios proporcionan los códigos de error? ¿Cuáles son las desventajas de usar códigos de error?
Con frecuencia utilizo códigos de error cuando es necesario transmitir un error al usuario, ya que pueden internacionalizarse. Por ejemplo, en un compilador, si hay errores en el código de usuario, los errores se pueden señalar en el backend del compilador, mientras que la interfaz puede ubicarlos en cadenas específicas de cultura / idioma para el consumo del usuario. Sin embargo, las enumeraciones pueden ser mejores para este propósito que los enteros en bruto.
También los he usado para crear un marco de "informe de errores" para la aplicación. Cuando se lanzaron las excepciones, se lanzaron con un código de error que, cuando se generó la excepción, se envió (con un registro) al servidor central. El código ayudó a organizar la base de datos para que pudiéramos inspeccionar los registros relacionados con un error específico.
Finalmente, como se mencionó en un par de otras respuestas, los códigos de error son fáciles y no hacen referencia al lenguaje de google (piense en los códigos de error de Windows / artículos de MS KB), por lo que un código de error con una descripción de lo que salió mal puede ser mejor para los usuarios finales Un producto técnico.
La idea de los códigos de error es útil, pero, en mi opinión, pertenecen como miembros de excepción o como parámetros a una interfaz de IErrorReporter o algo más que los valores de retorno de métodos.
He escrito muchos servicios web que son consumidos por otras aplicaciones (remotas). Cuando las cosas van mal con una solicitud, los clientes insisten más o menos en obtener un código, para que no tengan que hacer una comparación de cadenas horrible para descubrir qué salió mal.
Tome los códigos de resultado HTTP como un buen ejemplo de este tipo de comportamiento. "200" significa feliz, "300" podría ir en cualquier dirección, "400" o "500" significa comenzar a enloquecer.
Los códigos de error se diseñaron en una época en la que la única forma en que una función le dice a la persona que llama que algo salió mal fue asignar un significado especial a uno o más valores de los que pueden devolverse, y muy a menudo solo un entero nativo era Disponible para devolver ese valor especial.
Por ejemplo, en C, la rutina de "obtener carácter" devuelve el siguiente valor de carácter en ASCII, pero devuelve un valor negativo si, por alguna razón, algo salió mal. Entonces, usted es responsable de regresar a SU interlocutor de manera que pueda manejarse esta situación de error, y eso debe devolver, etc.
El mecanismo de excepción es una manera elegante de manejar esto "esto es una emergencia, debemos regresar del código hasta que algo pueda solucionar el problema". Los códigos de error son inferiores a esto.
Los códigos de error son de la vieja escuela. Son de poco o ningún valor en absoluto.
El único valor posible para un código de error es que puede identificar una circunstancia muy específica. Podría tener un código para cada punto en la base de código que pueda generar una excepción. Esto le permitiría reducir de manera muy precisa cuál debe ser el problema.
Pero a nadie le importa ese nivel de detalle. Quien quiera mantener tal lío. Le dejaría con códigos que significaban algo como "condición A y B pero no C debido al estado S". Es más esfuerzo de lo que vale la pena tratar de averiguar exactamente lo que eso significa. Una traza de pila será más valiosa para decirle en qué parte del programa ocurrió el problema.
Aprendí a programar computadoras antes de que las excepciones fueran una técnica generalizada. ¡Me alegro tanto de que tengamos excepciones!
Los códigos de error son para si desea enviarlos al usuario. Si no, use una excepción.
Muy común para interfaces de servicios web. Es muy fácil y estándar devolver un código con una descripción.
Estoy de acuerdo en que para la mayoría de los escenarios es de la vieja escuela
Yo diría que las mayores desventajas es la calidad del código. Debe agregar una lógica más compleja para administrar los códigos de error, mientras que las excepciones se burbujean sin tener que usar parámetros de método o valores de retorno.
También tiene que agregar un "SI" para verificar si el código devuelto tiene éxito o no, mientras que las excepciones van directamente al bloque de manejo de errores.
Soy un novato para apilar desbordamiento pero ...
Creo que los códigos de error tienden a ser usados o útiles para tratar situaciones erróneas que requieren un tipo de usuario final para involucrarse y rectificar una situación. Si su código debe ser mantenido por otro desarrollador, entonces las excepciones son el camino a seguir. Sin embargo, en una situación donde hay un problema:
en el entorno en el que se ejecuta su aplicación
con comunicación entre su aplicación y alguna otra entidad (servidor web, base de datos, socket, etc.)
que indica un dispositivo o controlador de dispositivo (¿falla el hardware?)
entonces los códigos de error pueden tener sentido. Por ejemplo, si su aplicación intentó iniciar sesión en una base de datos en nombre de su usuario final, pero la base de datos no estaba disponible para la autenticación (la base de datos está fuera de línea, el cable está desconectado), entonces una combinación de código / descripción de error podría ayudar al final. usuario rectificar el problema.
Nuevamente a nivel de desarrollador / ingeniero, quienes podrán tocar el código fuente (técnicas tradicionales de prueba y depuración) y modificarlo, usar excepciones.
Espero que esto ayude...
--jqpdev
DENTRO de un programa, siempre se deben usar excepciones en lugar de códigos de error. Sin embargo, las excepciones no pueden propagarse más allá de un programa. Cada vez que el error debe abandonar el programa, se le dejan mensajes de error o códigos de error.
Para cosas simples que siempre serán mensajes de error operados por humanos sin códigos están bien. Puede decir "Archivo no encontrado" sin darle un código de error. Sin embargo, si pudiera ser otra computadora en el otro extremo, debería agregar códigos de error. No desea romper el otro sistema cuando lo cambia a "Archivo <x> no encontrado".
No creo haber usado nunca códigos de error en .Net, excepto en una situación: cuando estaba creando una aplicación de consola que sabía que iba a ser llamada desde otra aplicación. Esta otra aplicación tenía que saber cuándo fallaba la aplicación de la consola y qué fallaba. Por lo tanto, un ejemplo de cuándo sería apropiado sería cuando usted sabe que otros programas llamarán a su programa y desea una forma estructurada para que comprendan los errores.
Dicho esto, yo era un novato en .NET en ese momento y desde entonces nunca he usado códigos de error.
Como nota al margen, como usuario de Windows, es bueno poder introducir un código de error y crear un artículo de KB, así que un código de error combinado con una buena documentación y la capacidad de encontrar los sentimientos agradables de los usuarios.