¿Son las variables de error un antipatrón o un buen diseño?

Para manejar varios posibles errores que no deberían detener la ejecución, tengo una errorvariable que los clientes pueden verificar y usar para lanzar excepciones. ¿Es esto un antipatrón? ¿Hay una mejor manera de manejar esto? Para ver un ejemplo de esto en acción, puede ver la API mysqli de PHP . Suponga que los problemas de visibilidad (accesores, ámbito público y privado, ¿es la variable en una clase o global?) Se manejan correctamente.

Si un lenguaje admite inherentemente excepciones, entonces se prefiere lanzar excepciones y los clientes pueden detectar la excepción si no quieren que resulte en una falla. De hecho, los clientes de su código esperan excepciones y se encontrarán con muchos errores porque no verificarán los valores de retorno.

Hay bastantes ventajas al usar excepciones si tiene una opción.

Mensajes

Las excepciones contienen mensajes de error legibles por el usuario que los desarrolladores pueden usar para depurar o incluso mostrar a los usuarios si así lo desean. Si el código consumidor no puede manejar la excepción, siempre puede registrarlo para que los desarrolladores puedan revisar los registros sin tener que detenerse en cualquier otro rastro para descubrir cuál era el valor de retorno y mapearlo en una tabla para descubrir cuál era excepción real

Con los valores de retorno, no hay información adicional que pueda proporcionarse fácilmente. Algunos idiomas admitirán la realización de llamadas a métodos para obtener el último mensaje de error, por lo que esta preocupación se disipa un poco, pero eso requiere que la persona que llama realice llamadas adicionales y, a veces, requerirá acceso a un 'objeto especial' que lleve esta información.

En el caso de mensajes de excepción, proporciono la mayor cantidad de contexto posible, como:

No se pudo recuperar una política de nombre "foo" para la "barra" del usuario, a la que se hizo referencia en el perfil del usuario.

Compare esto con un código de retorno -85. ¿Cuál preferirías?

Pilas de llamadas

Las excepciones generalmente también tienen pilas de llamadas detalladas que ayudan a depurar el código más rápido y más rápido, y también pueden registrarse mediante el código de llamada si así lo desea. Esto permite a los desarrolladores identificar el problema generalmente en la línea exacta y, por lo tanto, es muy poderoso. Una vez más, compare esto con un archivo de registro con valores de retorno (como -85, 101, 0, etc.), ¿cuál preferiría?

Enfoque fallido sesgado rápido

Si se llama a un método en algún lugar que falla, arrojará una excepción. El código de llamada tiene que suprimir la excepción explícitamente o fallará. He descubierto que esto es realmente sorprendente porque durante el desarrollo y las pruebas (e incluso en la producción) el código falla rápidamente, lo que obliga a los desarrolladores a solucionarlo. En el caso de los valores de retorno, si se omite la comprobación de un valor de retorno, el error se ignora silenciosamente y el error aparece en algún lugar inesperado, generalmente con un costo mucho mayor para depurar y corregir.

Envolviendo y desenvolviendo excepciones

Las excepciones pueden envolverse dentro de otras excepciones y luego desenvolverse si es necesario. Por ejemplo, su código podría arrojar el ArgumentNullExceptioncual el código de llamada podría envolverse dentro de una UnableToRetrievePolicyExceptionporque esa operación había fallado en el código de llamada. Si bien es posible que se muestre al usuario un mensaje similar al ejemplo que proporcioné anteriormente, algunos códigos de diagnóstico pueden desenvolver la excepción y descubrir que se ArgumentNullExceptionha producido el problema, lo que significa que es un error de codificación en el código de su consumidor. Esto podría activar una alerta para que el desarrollador pueda arreglar el código. Tales escenarios avanzados no son fáciles de implementar con los valores de retorno.

Simplicidad de código

Este es un poco más difícil de explicar, pero aprendí a través de esta codificación tanto con valores de retorno como con excepciones. El código que se escribió utilizando valores de retorno generalmente haría una llamada y luego verificaría cuál era el valor de retorno. En algunos casos, llamaría a otro método y ahora tendrá otra serie de comprobaciones para los valores de retorno de ese método. Con excepciones, el manejo de excepciones es mucho más simple en la mayoría, si no en todos los casos. Tiene un bloque try / catch / finally, con el tiempo de ejecución haciendo todo lo posible para ejecutar el código en los bloques finalmente para la limpieza. Incluso los bloques anidados try / catch / finally son relativamente más fáciles de seguir y mantener que los valores anidados if / else y los valores de retorno asociados de múltiples métodos.

Conclusión

Si la plataforma que está utilizando admite excepciones (especialmente, como Java o .NET), entonces definitivamente debe suponer que no hay otra forma, excepto lanzar excepciones porque estas plataformas tienen pautas para lanzar excepciones, y sus clientes esperan entonces. Si estuviera usando su biblioteca, no me molestaría en verificar los valores de retorno porque espero que se produzcan excepciones, así es el mundo en estas plataformas.

Sin embargo, si fuera C ++, sería un poco más difícil determinarlo porque ya existe una gran base de código con códigos de retorno, y una gran cantidad de desarrolladores están sintonizados para devolver valores en lugar de excepciones (por ejemplo, Windows está plagado de HRESULT) . Además, en muchas aplicaciones, también puede ser un problema de rendimiento (o al menos percibido).

Las variables de error son una reliquia de lenguajes como C, donde las excepciones no estaban disponibles. Hoy, debe evitarlos, excepto cuando está escribiendo una biblioteca que se utiliza potencialmente desde un programa en C (o un lenguaje similar sin manejo de excepciones).

Por supuesto, si tiene un tipo de error que podría clasificarse mejor como "advertencia" (= su biblioteca puede entregar un resultado válido y la persona que llama puede ignorar la advertencia si cree que no es importante), entonces un indicador de estado en forma de una variable puede tener sentido incluso en idiomas con excepciones. Pero cuidado. Las personas que llaman de la biblioteca tienden a ignorar tales advertencias incluso si no deberían hacerlo. Así que piénselo dos veces antes de introducir tal construcción en su lib.

Hay varias formas de señalar un error:

• una variable de error para verificar: C , Ir , ...
• una excepción: Java , C # , ...
• un controlador de "condición": Lisp (¿solo?), ...
• un retorno polimórfico: Haskell , ML , Rust , ...

El problema de la variable de error es que es fácil olvidar verificar.

El problema de las excepciones es que crea rutas ocultas de ejecuciones y, aunque try / catch es fácil de escribir, garantizar una recuperación adecuada en la cláusula catch es realmente difícil de lograr (no es compatible con los sistemas de tipo / compiladores).

El problema de los controladores de condiciones es que no se componen bien: si tiene una ejecución dinámica de código (funciones virtuales), entonces es imposible predecir qué condiciones deben manejarse. Además, si se puede plantear la misma condición en varios puntos, no se sabe si se puede aplicar una solución uniforme cada vez, y rápidamente se vuelve desordenada.

Los retornos polimórficos ( Either a ben Haskell) son mi solución favorita hasta ahora:

• explícito: sin ruta oculta de ejecución
• explícito: completamente documentado en la firma del tipo de función (sin sorpresas)
• difícil de ignorar: debe coincidir con el patrón para obtener el resultado deseado y manejar el caso de error

El único problema es que potencialmente pueden conducir a una verificación excesiva; los idiomas que los usan tienen modismos para encadenar las llamadas de funciones que los usan, pero aún puede requerir un poco más de tipeo / desorden. En Haskell esto sería mónadas ; sin embargo, esto es mucho más aterrador de lo que parece, vea Programación orientada al ferrocarril .

Creo que es horrible Actualmente estoy refactorizando una aplicación Java que usa valores de retorno en lugar de excepciones. Aunque es posible que no esté trabajando con Java, creo que esto se aplica de todos modos.

Terminas con un código como este:

String result = x.doActionA();
if (result != null) {
  throw new Exception(result);
}
result = x.doActionB();
if (result != null) {
  throw new Exception(result);
}

O esto:

if (!x.doActionA()) {
  throw new Exception(x.getError());
}
if (!x.doActionB()) {
  throw new Exception(x.getError());
}

Prefiero que las acciones arrojen excepciones, por lo que terminas con algo como:

x.doActionA();
x.doActionB();

Puede envolverlo en un intento de captura y obtener el mensaje de la excepción, o puede elegir ignorar la excepción, por ejemplo, cuando está eliminando algo que ya puede haber desaparecido. También conserva su rastro de pila, si tiene uno. Los métodos mismos también se vuelven más fáciles. En lugar de manejar las excepciones ellos mismos, simplemente arrojan lo que salió mal.

Código actual (horrible):

private String doActionA() {
  try {
    someOperationThatCanGoWrong1();
    someOperationThatCanGoWrong2();
    someOperationThatCanGoWrong3();
    return null;
  } catch(Exception e) {
    return "Something went wrong!";
  }
}

Nuevo y mejorado:

private void doActionA() throws Exception {
  someOperationThatCanGoWrong1();
  someOperationThatCanGoWrong2();
  someOperationThatCanGoWrong3();
}

Strack trace se conserva y el mensaje está disponible en la excepción, en lugar del inútil "¡Algo salió mal!".

Por supuesto, puede proporcionar mejores mensajes de error, y debería. Pero esta publicación está aquí porque el código actual en el que estoy trabajando es un fastidio, y no debes hacer lo mismo.

"Para manejar varios posibles errores que suceden, eso no debería detener la ejecución"

Si quiere decir que los errores no deberían detener la ejecución de la función actual, sino que deberían informarse a la persona que llama de alguna manera, entonces tiene algunas opciones que realmente no se han mencionado. Este caso es realmente más una advertencia que un error. Lanzar / Devolver no es una opción, ya que finaliza la función actual. Un solo parámetro de mensaje de error o retorno solo permite que ocurra uno de estos errores como máximo.

Dos patrones que he usado son:

• Una colección de error / advertencia, ya sea pasada o mantenida como una variable miembro. A lo que agregas cosas y simplemente continúas procesando Personalmente, no me gusta mucho este enfoque, ya que siento que le quita el poder a la persona que llama.

• Pase un objeto controlador de error / advertencia (o configúrelo como una variable miembro). Y cada error llama a una función miembro del controlador. De esta manera, la persona que llama puede decidir qué hacer con tales errores que no terminan.

Lo que pasa a estas colecciones / controladores debe contener suficiente contexto para que el error se maneje "correctamente": una cadena suele ser demasiado pequeña, pasarle alguna instancia de Excepción a menudo es razonable, pero a veces está mal visto (como un abuso de Excepciones) .

El código típico que usa un controlador de errores podría verse así

class MyFunClass {
  public interface ErrorHandler {
     void onError(Exception e);
     void onWarning(Exception e);
  }

  ErrorHandler eh;

  public void canFail(int i) {
     if(i==0) {
        if(eh!=null) eh.onWarning(new Exception("canFail shouldn't be called with i=0"));
     }
     if(i==1) {
        if(eh!=null) eh.onError(new Exception("canFail called with i=1 is fatal");
        throw new RuntimeException("canFail called with i=2");
     }
     if(i==2) {
        if(eh!=null) eh.onError(new Exception("canFail called with i=2 is an error, but not fatal"));
     }
  }
}

A menudo no hay nada de malo en usar este patrón o ese patrón, siempre que use el patrón que todos los demás usan. En el desarrollo de Objective-C , el patrón preferido es pasar un puntero donde el método que se llama puede depositar un objeto NSError. Las excepciones están reservadas para errores de programación y conducen a un bloqueo (a menos que tenga programadores Java o .NET escribiendo su primera aplicación para iPhone). Y esto funciona bastante bien.

La pregunta ya está respondida, pero no puedo evitarlo.

Realmente no puede esperar que Exception proporcione una solución para todos los casos de uso. ¿Martillar a alguien?

Hay casos en que las Excepciones no son el final de todo y son todas, por ejemplo, si un método recibe una solicitud y es responsable de validar todos los campos pasados, y no solo el primero, entonces debe pensar que debería ser posible indique la causa del error para más de un campo. También debería ser posible indicar si la naturaleza de la validación impide que el usuario vaya más allá o no. Un ejemplo de eso sería una contraseña no segura. Puede mostrar un mensaje al usuario que indique que la contraseña ingresada no es muy segura, pero que es lo suficientemente segura.

Se podría argumentar que todas estas validaciones se podrían lanzar como una excepción al final del módulo de validación, pero serían códigos de error en cualquier cosa menos en el nombre.

Entonces, la lección aquí es: las excepciones tienen su lugar, al igual que los códigos de error. Elije sabiamente.

Hay casos de uso donde los códigos de error son preferibles a las excepciones.

Si su código puede continuar a pesar del error, pero necesita un informe, entonces una excepción es una mala elección porque las excepciones terminan el flujo. Por ejemplo, si está leyendo un archivo de datos y descubre que contiene datos incorrectos no terminales, podría ser mejor leer el resto del archivo e informar el error en lugar de fallar directamente.

Las otras respuestas han cubierto por qué las excepciones deberían preferirse a los códigos de error en general.

Definitivamente no hay nada de malo en no usar excepciones cuando las excepciones no se ajustan bien.

Cuando no se debe interrumpir la ejecución del código (por ejemplo, actuar sobre la entrada del usuario que puede contener múltiples errores, como un programa para compilar o un formulario para procesar), encuentro que recopilar errores en variables de error como has_errorsy error_messageses, de hecho, un diseño mucho más elegante que lanzar Una excepción en el primer error. Permite encontrar todos los errores en la entrada del usuario sin obligarlo a volver a enviarlo innecesariamente.

En algunos lenguajes de programación dinámicos puede usar tanto valores de error como manejo de excepciones . Esto se hace devolviendo el objeto de excepción no lanzado en lugar del valor de retorno ordinario, que puede verificarse como un valor de error, pero arroja una excepción si no se verifica.

En Perl 6 se hace a través de fail, que si dentro del no fatal;alcance devuelve un Failureobjeto de excepción especial no lanzado .

En Perl 5 puede usar Contextual :: Return con el que puede hacer esto return FAIL.

A menos que haya algo muy específico, creo que tener una variable de error para la validación es una mala idea. El propósito parece ser ahorrar tiempo dedicado a la validación (solo puede devolver el valor de la variable)

Pero luego, si cambia algo, debe volver a calcular ese valor de todos modos. Sin embargo, no puedo decir más sobre la detención y el lanzamiento de excepciones.

EDITAR: No me di cuenta de que esta es una cuestión de paradigma de software en lugar de un caso específico.

Permítanme aclarar más mis puntos en un caso particular mío en el que mi respuesta tendría sentido

1. Tengo una colección de objetos de entidad.
2. Tengo servicios web de estilo de procedimiento que funcionan con estos objetos de entidad

Hay dos tipos de errores:

1. Los errores cuando el procesamiento ocurre en la capa de servicio
2. Los errores porque hay inconsistencias en los objetos de la entidad.

En la capa de servicio, no hay otra opción que usar el objeto Resultado como contenedor, que es la variable de equivalencia de error. Es posible simular una excepción a través de una llamada de servicio en un protocolo como http, pero definitivamente no es algo bueno. No estoy hablando de este tipo de error y no pensé que este es el tipo de error que se hace en esta pregunta.

Estaba pensando en el segundo tipo de error. Y mi respuesta es sobre este segundo tipo de errores. En los objetos de entidad, hay opciones para nosotros, algunos de ellos son

• usando una variable de validación
• lanzar una excepción inmediatamente cuando un campo se establece incorrectamente desde el colocador

Usar la variable de validación es lo mismo que tener un único método de validación para cada objeto de entidad. En particular, el usuario puede establecer el valor de una manera que mantenga al setter como un setter puro, sin efectos secundarios (esto es a menudo una buena práctica) o uno puede incorporar la validación en cada setter y luego guardar el resultado en una variable de validación. La ventaja de esto sería ahorrar tiempo, el resultado de la validación se almacena en caché en la variable de validación para que cuando el usuario llame a validación () varias veces, no haya necesidad de hacer una validación múltiple.

Lo mejor que se puede hacer en este caso es usar un único método de validación sin siquiera usar ningún error de validación para validar en caché. Esto ayuda a mantener el setter como solo setter.