Confundido sobre std :: runtime_error contra std :: logic_error

Question

Recientemente vi que la biblioteca impulsar program_options lanza un logic_error si la entrada de la línea de comandos no se pudo analizar. Eso desafió mis suposiciones sobre logic_error contra runtime_error.

Supuse que los errores lógicos (logic_error y sus clases derivadas) eran problemas que resultaban de fallas internas para adherirse a las invariantes del programa, a menudo en forma de argumentos ilegales para las API internas. En ese sentido, son en gran parte equivalentes a ASSERT, pero destinados a ser utilizados en código liberado (a diferencia de ASSERT, que generalmente no se compilan en código publicado). Son útiles en situaciones donde no es factible integrar componentes de software separados en compilaciones de depuración/prueba o las consecuencias de una falla son tales que es importante dar retroalimentación en tiempo de ejecución sobre la condición invariable no válida para el usuario.

mismo modo, pensé que runtime_error s dieron como resultado exclusivamente de las condiciones de tiempo de ejecución fuera del control del programador: errores de E/S, la entrada de usuario no válido, etc.

Sin embargo, program_options es, obviamente, muy usado (principalmente?) como un medio para analizar la entrada del usuario final, entonces bajo mi modelo mental ciertamente debería arrojar un runtime_error en el caso de una mala entrada.

¿Dónde me estoy equivocando? ¿Estás de acuerdo con el modelo de impulso del tipeo de excepciones?

Answer 1

En este caso, creo (al menos en su mayor parte) tienes razón y está mal. La norma describe logic_error como:

El logic_error clase define el tipo de objetos lanzados como excepciones para informar de errores presumiblemente detectables antes de ejecuta el programa, tales como violaciónes de condiciones previas lógicas o invariantes de clase.

Un argumento de línea de comandos que no se puede analizar no parece encajar muy bien.

Por el contrario, describe runtime_error como:

El runtime_error clase define el tipo de objetos arrojados como excepciones para informar de errores presumiblemente detectable sólo cuando el programa se ejecuta.

Ese parece ser un mejor ajuste.

Answer 2

El proyecto actual de la 0x Standard C++ dice (cláusula 19.2):

1) En el modelo de error refleja en estas clases (es decir, los tipos de excepciones), los errores se dividen en dos categorías amplias: errores de lógica y errores de tiempo de ejecución .

2) La característica distintiva de errores de lógica es que son debido a errores en la lógica interna del programa . En teoría, son prevenibles.

3) Por el contrario, los errores de tiempo de ejecución se deben a a eventos fuera del alcance del programa . No pueden ser fácilmente pronosticados de antemano.

Junto con las cotizaciones citadas en una de las otras respuestas Esto explica por qué Boost.ProgramOptions lanza un std :: logic_error de errores evitables causadas por un 'error de suponer detectable antes de que el programa se ejecuta'.

Answer 3

Desde el punto de vista del estándar puro, tiene razón. program_options debe lanzar clases derivadas de runtime_error o logic_error dependiendo de si el error es en tiempo de ejecución o lógico. (No revisé el código actual para determinar dicha clasificación de idea para las excepciones actuales).

Desde un punto de vista práctico, aún no he visto el código C++ que toma decisiones útiles en función de si la excepción es logic_error o runtime_error. Después de todo, la única razón por la que arrojaría un logic_error en lugar de dejar que afirme el archivo es si desea intentar recuperar de alguna manera, y eso no es diferente de la recuperación de un error de tiempo de ejecución. Personalmente, veo logic_error frente a runtime_error de la misma manera que las excepciones comprobadas en Java: teóricamente agradable, pero no útil en la práctica. Lo que significa que, tal vez, haré que program_options::error derive de exception. Es decir, cuando encuentre ese "tiempo libre", todo el mundo sigue hablando.

Answer 4

El usuario puede verificar que el archivo existe, ejecutar el programa y, de repente, saber que el archivo se ha eliminado. Es por eso que un problema de E/S siempre es un runtime_error. Los problemas de estado son runtime_errors, incluso si la persona que llama pudo haber verificado, ya que otro hilo podría causar el problema.

logic_error es cuando los argumentos para una función son incorrectos. Es solo para cosas que podrían haber sido detectadas anteriormente con una verificación de tipo más fuerte.

Por lo tanto, "archivo faltante" es un runtime_error, pero "nombre de archivo formateado incorrectamente" es un logic_error.

Técnicamente, un error lógico dentro de una función es un logic_error también, pero si usted es lo suficientemente inteligente como para probar que dentro de su propia función, que debe ser lo suficientemente inteligente como para evitar que en el primer lugar.

Answer 5

OMI,

• std::logic_error es lanzada por un programa lógica intencionalmente usuario C++. Predicho por un programa de usuario.

• std::runtime_error es lanzada por un tiempo de ejecución C++ (o parte central del langauge ...) a los errores abstractos de nivel inferior. Simplemente sucede sin ninguna intención sin la participación de ningún código de usuario.