sobre las excepciones de c ++. func () throw ()
Pregunta
estoy leyendo esta página http://www.cplusplus.com/doc/tutorial /exceptions.html dice si escribo function () throw (); no se pueden lanzar excepciones en esa función. Intenté en msvc 2005 escribiendo throw (), throw (int), throw () y nada en absoluto. cada uno tuvo exactamente los mismos resultados. Nada. Lancé int, char *, otro tipo y todo fue capturado de la misma manera. Parece que el tiro no lo afecta en absoluto. ¿Qué hace realmente function () throw ()?
Solución
Consulte este artículo para obtener detalles sobre las especificaciones de excepción de C ++ y la implementación de Microsoft:
Microsoft Visual C ++ 7.1 ignora las especificaciones de excepción a menos que estén vacías. Las especificaciones de excepción vacías son equivalentes a
__declspec (nothrow)
, y pueden ayudar al compilador a reducir el tamaño del código.[...] Si ve una especificación de excepción vacía, asumirá que sabe lo que está haciendo y optimizará la mecánica para manejar las excepciones. Si tu función es de todos modos, bueno, la culpa es tuya. Use esta función solo si está 100% seguro de que su función no se lanza y nunca lo hará.
Otros consejos
Lo que estás encontrando es que esa versión de VC ++ no impuso excepciones de especificación. Creo que eso fue documentado como una variación de la norma.
Sin embargo, las especificaciones de excepción generalmente no son una buena idea. Si un programa los viola en una implementación que cumple con los estándares (que VC ++ de VS 2005 no era en este caso), se supone que el sistema lo detectará. Esto significa que la especificación no es una sugerencia de optimización del compilador, sino que obliga al compilador a ir más allá y, a veces, a producir un código subóptimo.
Consulte la justificación de Boost para conocer los motivos por los que Boost es muy apreciado. proyecto no utiliza especificaciones de excepción. Esto es Boost, que es algo del niño del póster para hacer cosas extrañas y útiles con partes avanzadas del lenguaje.
Citas de Una mirada pragmática a las especificaciones de excepción :
(Mis)comercados
El segundo problema tiene que ver con sabiendo lo que estás obteniendo. Como muchos personas notables, incluidos los autores de la especificación de excepción Boost justificación, lo he puesto, los programadores tienden a usar excepciones especificaciones como si se comportaran la forma en que le gustaría al programador, en lugar de la forma en que lo hacen realmente comportarse.
Aquí & # 8217; s lo que mucha gente piensa que las especificaciones de excepción hacen:
Garantiza que las funciones solo lanzarán las excepciones enumeradas (posiblemente ninguno).
Habilita las optimizaciones del compilador basadas en el conocimiento que solo aparece excepciones (posiblemente ninguna) serán arrojado.
Las expectativas anteriores son, de nuevo, engañosamente cerca de ser correcto.
Vea el enlace para obtener todos los detalles.
Lanzar una excepción no es suficiente, necesita un bloque try {} catch ()
para capturar excepciones. Si no detecta excepciones, se llama a std :: terminate ()
y su programa se cierra abruptamente. Tómese un tiempo y vaya a esto .
especificaciones de lanzamiento están diseñadas para dos propósitos:
-
Para servir como un contrato entre la interfaz implementada y el usuario de la interfaz: usted establece qué excepciones pueden ser lanzadas desde su método, algunas personas lo consideran parte de una interfaz. (contrato) Ala verificó excepciones en Java.
-
Como una forma de indicarle al compilador que puede aplicar ciertas optimizaciones en caso de que no se puedan generar excepciones de un método / procedimiento (configurar la gestión de excepciones cuesta algo)
Lanzar una excepción no especificada en la cláusula throw () es un error, sin embargo, en ningún momento se requiere la implementación para verificarlo . De hecho, ni siquiera es posible verificarlo, ya que incluye todas las excepciones posibles de las subrutinas a las que llama. (posiblemente de otros módulos) Ni siquiera es posible dentro de un solo módulo, ya que se reduce fácilmente a un problema de detención :)