tirar, volver o errno?

Question

Estoy creando un sistema. Lo que quiero saber es si un mensaje no es compatible, ¿qué debería hacer? ¿Debo lanzar diciendo msg no compatible? ¿Debo devolver 0 o -1? o debería establecer un errno (base- > errno_). Algunos mensajes no me importarían si hubiera un error (como setBorderColour). Otros lo harían (addText o quizás guardar si creo un cmd save).

Quiero saber cuál es el mejor método para 1) codificar rápidamente 2) depurar 3) extender y mantener. Puedo hacer que la depuración sea tercera, es difícil depurar el cajero automático, pero eso es porque falta mucho código que no completé. Los errores reales no son difíciles de corregir. ¿Cuál es la mejor manera de informar al usuario que hay un error?

El sistema funciona de esta manera pero no exactamente lo mismo. Este es el estilo C y mycode tiene un montón de funciones en línea que envuelven settext (const char * text) {a msg (this, esettext, text)

Base base2, base;
base = get_root();
base2 = msg(base, create, BASE_TYPE);
msg(base2, setText, "my text");
const char *p = (const char *)msg(base2, getText);

Answer 1

Generalmente, si se trata de C ++, prefiera excepciones a menos que el rendimiento sea crítico o que pueda estar ejecutándose en un entorno (por ejemplo, una plataforma integrada) que no admite excepciones. Las excepciones son, con mucho, la mejor opción para la depuración porque son muy notables cuando ocurren y se ignoran. Además, las excepciones son autodocumentadas. Tienen su propio nombre de tipo y generalmente un mensaje contenido que explica el error. Los códigos de retorno y errno requieren definiciones de código separadas y algún tipo de forma fuera de banda de comunicar lo que significan los códigos en cualquier contexto dado (por ejemplo, páginas de manual, comentarios).

Para codificar rápidamente, los códigos de retorno son probablemente más fáciles, ya que no implican la posibilidad de definir sus propios tipos de excepción y, a menudo, el código de verificación de errores no es tan detallado como con las excepciones. Pero, por supuesto, el gran riesgo es que es mucho más fácil ignorar silenciosamente los códigos de retorno de error, lo que genera problemas que pueden no notarse hasta mucho después de que ocurran, lo que convierte la depuración y el mantenimiento en una pesadilla.

Intenta evitar usar errno, ya que es muy propenso a errores. Es global, por lo que nunca se sabe quién lo está restableciendo, y definitivamente es no seguro para subprocesos.

Editar: me acabo de dar cuenta de que te referías a una variable miembro errno y no al errno de estilo C. Eso es mejor porque no es global, pero aún necesita construcciones adicionales para que sea seguro para subprocesos (si su aplicación es multiproceso), y conserva todos los problemas de un código de retorno.

Answer 2

Devolver un código de error requiere disciplina porque el código de error debe verificarse explícitamente y luego pasarlo por alto. Escribimos un gran sistema basado en C que usó este enfoque y tardó un tiempo en eliminar todos los "perdidos". errores Eventualmente desarrollamos algunas técnicas para detectar este problema (como almacenar el código de error en una ubicación global de subprocesos y verificar en el nivel superior para ver si el código de error devuelto coincidía con el código de error guardado).

El manejo de excepciones es más fácil de codificar rápidamente porque si está escribiendo código y no está seguro de cómo manejar el error, puede dejar que se propague hacia arriba (suponiendo que no esté utilizando Java donde tiene que lidiar con excepciones marcadas). Es mejor para la depuración porque puede obtener un seguimiento de la pila de dónde ocurrió la excepción (y porque puede crear controladores de excepciones de nivel superior para detectar problemas que deberían haberse detectado en otro lugar). Es mejor para mantener porque si ha hecho las cosas bien, se le notificará el problema más rápido.

Sin embargo, hay algunos problemas de diseño con el manejo de excepciones, y si te equivocas, estarás peor. En resumen, si está escribiendo código que no sabe cómo manejar una excepción, debe dejar que se propague. Demasiados codificadores atrapan errores solo para convertir la excepción y luego volver a lanzarla, lo que da como resultado un código de excepción de espagueti que a veces pierde información sobre la causa original del problema. Esto supone que tiene controladores de excepciones en el nivel superior (puntos de entrada).

Answer 3

Personalmente cuando se trata de gráficos de salida, siento que un fallo silencioso está bien. Simplemente hace que tu imagen sea incorrecta.

Los errores gráficos son muy fáciles de detectar de todos modos.

Answer 4

Personalmente, agregaría un error a su estructura Base si es pura 'C'. Si esto es C ++, lanzaría una excepción.

Depende de cuán 'fatales' sean estos errores. ¿El usuario realmente necesita ver el error, o es para la edificación de otros desarrolladores?

Para el mantenimiento, debe documentar claramente los errores que pueden ocurrir e incluir ejemplos claros de manejo de errores.