c++ - usar - question tags ejemplos

¿Tiene sentido detectar excepciones en general(...)?

Question

Encontré un código en un proyecto que se ve así:

int main(int argc, char *argv[])
{
  // some stuff

 try {
  theApp.Run();
 } catch (std::exception& exc) {
  cerr << exc.what() << std::endl;
  exit(EXIT_FAILURE);
 }
 return (EXIT_SUCCESS);
}

No entiendo por qué las excepciones están siendo atrapadas. Si no lo fueran, la aplicación simplemente saldría y la excepción se imprimiría.

¿Ves alguna buena razón para detectar excepciones aquí?

EDITAR: Estoy de acuerdo en que es bueno imprimir el error de excepción. Sin embargo, ¿no sería mejor volver a lanzar la excepción? Tengo la sensación de que estamos tragándolo aquí ...

Answer 1

¿Por qué dices que la excepción se imprimirá? Este no es el comportamiento típico del tiempo de ejecución de C ++. En el mejor de los casos, puede esperar que su tipo se imprima.

Además, este programa deja un estado de "falla", mientras que una excepción puede causar un estado de finalización de interrupción (es decir, con una señal indicada en el código de salida).

Answer 2

Este es un bloque de captura global. Es común que se muestre un mensaje agradable y entendido por el usuario ("Error interno") en lugar de una impresión de excepción críptica. Esto puede no ser evidente desde el bloque de código específico, pero en general es una buena idea.

Answer 3

Si no se detecta una excepción, el estándar no define si la pila se desenrolla. Por lo tanto, en algunas plataformas se invocarán destructores, y en otros el programa terminará inmediatamente. La captura en el nivel superior asegura que los destructores siempre sean llamados.

Por lo tanto, si no se está ejecutando bajo el depurador, es probable que atrape todo: (...) y std :: exception. Entonces su código de aplicación puede limpiarse con RAII incluso en una excepción fatal. En muchos casos, en realidad no necesita limpiar, ya que el sistema operativo lo hará por usted. Pero, por ejemplo, es posible que prefiera desconectarse limpiamente de los servicios remotos siempre que sea posible, y podría haber recursos externos al proceso, como named pipes / mutexes, que preferiría destruir en lugar de fugas.

Retirar la excepción en main me parece de uso limitado, ya que ya has perdido el contexto en el que se lanzó originalmente. Supongo que atrapar una excepción no detectada en el depurador es más ruidoso que simplemente registrar la falla en std :: cerr, por lo que volver a lanzar sería una decisión inteligente si existe la posibilidad de perder el registro.

Si desea que el depurador atrape condiciones inesperadas en el modo de depuración, que en el modo de lanzamiento arroja una excepción que finalmente da como resultado una salida, existen otras formas de hacerlo que dejar la excepción no detectada para que el depurador la vea. Por ejemplo, puede usar assert macros. Por supuesto, eso no ayuda con las condiciones inesperadas e impredecibles, como las excepciones de hardware si está utilizando SEH en .NET.

Answer 4

Try-catch en la función principal oculta la excepción del depurador. Yo diría que no es bueno.

Por otro lado, no se espera que los clientes tengan depuradores, por lo que capturar excepciones es agradable. Entonces es bueno

Personalmente, capturo todas las excepciones en la función principal, cuando realizo una versión de lanzamiento, y no hago eso, cuando construyo una configuración de depuración.

Answer 5

Eche un vistazo a la Biblia de C ++, es decir Stroustrup, tiene un ejemplo que también se repite en la programación de C ++ aplicada. El razonamiento es:

int main(void)
{
     try
     {
          // your code 
     }
     catch ( /* YourPossibleExceptions i.e. barfs you expect may occur */ )
     {
     }
     catch ( ... ) // unexpected errors, so you can exit gracefully
     {
     }
}

Answer 6

Según las especificaciones de Windows, el main no puede lanzar. (prácticamente resulta en el mensaje que le pregunta si desea enviar el informe de error a Microsoft)

Answer 7

Un simple ejemplo de una situación donde la pila no se relajó:
¿Por qué no se llama a destructor a la excepción?

Una lista de situaciones en las que las excepciones pueden causar que la aplicación finalice en lugar de desenrollar la pila.
¿Por qué no se llama a destructor a la excepción?

Si una excepción no se detecta en ningún nivel y escaparía de main (), entonces la implementación puede llamar a terminate () en lugar de desenrollar la pila (sí, esto también me tomó por sorpresa).

Como resultado, siempre capturo todas las excepciones en main ().

int main()
{
    try
    {
    }
    catch(std::exception const& e)
    {  /* LOG */
       // optimally rethrow
    }
    catch(...) // Catch anything else.
    {  /* LOG */
       // optimally rethrow
    }
}

Para ayudar a detectar problemas durante la depuración. Derive sus excepciones de std :: exception y luego pegue el punto de ruptura en el constructor para std :: exception.