c++ - studio - void value not ignored as it ought to be arduino

Manejo de errores en C++: ¿buenas fuentes de código de ejemplo?

Question

Casi todos los códigos de ejemplo en todas partes omiten el manejo de errores (porque "confunde el problema" al que se dirige el código de ejemplo). Mi conocimiento de programación proviene principalmente de libros y sitios web, y rara vez se ve un manejo de errores en uso, y mucho menos cosas buenas.

¿Dónde hay algunos lugares para ver buenos ejemplos del código de manejo de errores de C ++? Se aceptarán con agradecimiento los libros específicos, los proyectos específicos de código abierto (preferiblemente con los archivos y las funciones para observar) y las páginas web o sitios específicos.

Answer 1

Con C ++, debería terminar con un código de manejo de errores menos visible de todos modos, porque puede dejar una gran cantidad de trabajo pesado a Excepciones.

En mi opinión, la regla más básica con excepciones (y la más común) es esta. No intente detectar excepciones a menos que tenga un plan específico para manejarlas.

Con excepciones, no tiene que preocuparse por los códigos de error devueltos por las funciones, porque las funciones bien diseñadas solo arrojarán excepciones.

En C, un escenario típico de manejo de errores tiene este aspecto:

int DoA() 
{
 if (location == hellInAHandcart)
  return ERROR;
 else
  RETURN OK;
}

int DoB()
{
  int err = DoA();
  if (err != OK)
     return err;
  else
     return DoSomethingElse1();
}

int DoC()
{
  int err = DoB();
  if (err != OK)
     //Handle My error here in whatever way...
}

Mientras estás en C ++ ...

void DoA() 
{
 if (location == hellInAHandcart)
  throw Exception("Gone To Hell in a Handcart");
}

void DoB()
{
  DoA();
  DoSomethingElse1();
}

void DoC()
{
  try
  {
    DoB();
  }
  catch (Exception &E)
  {
    // Handle My error here in whatever way...
  }
}

Answer 2

El libro C ++ Coding Standards de Herb Sutter y Andrei Alexandrescu incluye un capítulo completo sobre Manejo de errores y excepciones, que incluye

• Afirmar liberalmente para documentar supuestos e invariantes internos
• Establezca una política racional de manejo de errores, y sígala estrictamente
• Distinga entre errores y no errores
• Diseñar y escribir código de error
• Prefiere usar excepciones para informar errores
• Lanzar por valor, captura por referencia
• Reportar, manejar y traducir errores apropiadamente
• Evite las especificaciones de excepción

Cada tema también incluye un ejemplo y descubrí que es un recurso muy valioso.

Answer 3

Prefiero el manejo de excepciones discutido en este artículo. Resulta en código limpio y evita la creación / eliminación explícita de objetos solo para procesar excepciones. http://www.informit.com/articles/article.aspx?p=373339

Answer 4

"Usar excepciones" vs. "Usar códigos de error" nunca es tan claro como sugieren los ejemplos.

Use códigos de error para el flujo del programa. Si tiene un error esperado, no arroje una excepción. Por ejemplo, si está leyendo un archivo, puede lanzar una excepción para "archivo no encontrado" , "archivo bloqueado" ; pero nunca arroje uno para "fin de archivo" .

Si lo hace, nunca podrá escribir bucles simples, siempre estará envolviendo el código en manejadores de excepciones. Y no olvide que las excepciones son muy lentas, esto es especialmente importante en los grandes servidores multiproceso. (No tan importante en absoluto en su aplicación de escritorio).

En segundo lugar, tenga mucho cuidado con las jerarquías de excepción. Puede pensar que está bien tener una clase Exception , luego derivar una NetException de ella y luego SMTPException para su clase SMTP. Pero a menos que tenga datos genéricos en la clase base, siempre tendrá que atrapar todo tipo de excepción en esa jerarquía. Por ejemplo, si SMTPException el motivo del error SMTP en su clase SMTPException , debe detectarlo: si solo Exception tipos de Exception , no tendrá acceso a los miembros SMTPException . Una buena solución para este problema es tener una cadena y un miembro int en la clase de excepción base y solo usarlos, incluso para los tipos derivados. Desafortunadamente std::exception solo ofrece una cadena :(

Algunas personas dicen que hacer esto significa que también podría tener un solo tipo de excepción, especialmente porque de todos modos siempre captará el tipo de clase base.

Si usa excepciones, debe tomarse la molestia de completarlas con más datos de los que obtendría con un código de error. Con errores, debe manejarlos de inmediato o se pierden en el código. Con una excepción, puede quedar atrapada a muchos niveles de donde fue lanzada, como en el ejemplo de Roddy. Se llama a DoC y obtiene una excepción de 2 niveles desde DoA . A menos que especifique que el error es específico del código en DoA , puede pensar que fue lanzado desde la función DoB . (Ejemplo simple, pero he visto código en el que se manejaba una excepción en muchos niveles de la pila de llamadas. Se resolvió por completo depurar. Esto se aplica especialmente a los programas OO)

Así que con suerte, te di suficiente para que pienses. La simple verdad del asunto es que el estilo no significa nada en el manejo de errores, la practicidad lo es todo. Si tiene que colocar instrucciones de registro en todas partes, puede ocurrir un error, entonces hágalo. Importa mucho más que pueda ver dónde salió mal el código (y con qué datos se trabajó) que si tiene una elegante jerarquía de excepciones o si ha ensuciado su código con manejadores de excepciones. Si no puede rastrear fácilmente el error, su código de manejo de errores es inútil.

Las excepciones son buenas, úsalas. Pero piensa en lo que estás haciendo, no los malgastes ni los uses en exceso. Una excepción mal utilizada es peor que ningún manejo de errores (ya que puedes tomar un volcado de emergencia y ver la excepción no controlada para encontrar el error en segundos. Con una excepción que se come e ignora, estás relleno).

A lo largo de los años, descubrí que el mejor asistente para la depuración es el registro. Escribir registros, escribir muchos registros.