2009-03-02 14 views
8

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 escribir throw(), throw (int), throw() y nada en absoluto. cada uno tenía exactamente los mismos resultados. Nada. Lancé int, char *, otro tipo y todo se atrapó de la misma manera. Parece que throw no lo afecta en absoluto. ¿Qué hace function() throw() en realidad?sobre excepciones de C++. func() throw()

Respuesta

10

Ver this article para obtener detalles sobre las especificaciones de excepciones de C++ y la implementación de Microsoft:

Microsoft Visual C++ 7.1 ignora especificaciones de excepción a menos que estén vacíos. 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 usted sabe lo que está haciendo y optimizará las mecánicas para hacer frente a las excepciones. Si tu función arroja de todos modos, bueno, qué vergüenza. Utilice esta función solo si está 100% seguro de que su función no arroja y nunca lo hará.

+0

Eso es muy diferente de lo que dice la norma ... Supongo que una razón más para no usarlos –

+0

Gracias por la edición, Shog;) –

0

Lanzar una excepción no es suficiente, necesita un bloque try {} catch() para detectar excepciones. Si no detecta excepciones, se llama al std::terminate() y su programa se cierra abruptamente. Tómese un tiempo e ir al this.

+4

Que no es lo que estaba preguntando. –

0

especificaciones de tiro están diseñados para dos propósitos:

  1. Para servir como un contrato entre la interfaz implementada e interfaz de usuario - usted indica las excepciones que se pueden throwned de su método, algunas personas consideran que es parte de una interfaz . (contrato) Ala marcó excepciones en Java.

  2. Como una manera de indicar al compilador que se puede aplicar ciertas optimizaciones en caso de que no hay excepciones pueden ser lanzadas desde un método/procedimiento (la creación de excepción costos de manejo algo)

lanzar una excepción no especificada en la cláusula throw() es un error, sin embargo, en ningún momento es la implementación requerida para verificarlo para usted. De hecho, ni siquiera es posible verificarlo, ya que incluye todas las excepciones posibles de las subrutinas que subrutina 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 :)

+0

Completamente incorrecto para C++. Las especificaciones de excepción deben verificarse en tiempo de ejecución y, en general, no permiten optimizaciones. –

+0

Ese no es mi punto. No es necesario que se revisen en TIEMPO COMPLETO. También permiten la optimización en caso de NO EXCEPCIONES (en mi humilde opinión, las preguntas frecuentes en el lenguaje C++ lo mencionan). Entonces tu voto negativo es incorrecto. – EFraim

4

Lo que está descubriendo es que esa versión de VC++ no impone excepciones de especificación. Creo que eso fue documentado como una variación del estándar.

Sin embargo, las especificaciones de excepción no suelen ser una buena idea. Si un programa los viola en una implementación conforme a los estándares (que el VC++ de VS 2005 no fue en este caso), se supone que el sistema debe atraparlo. Esto significa que la especificación no es una sugerencia de optimización del compilador, sino que obliga al compilador a tomar medidas adicionales y, a veces, produce un código que no es óptimo.

Consulte the Boost rationale por las razones por las cuales el proyecto Boost de gran prestigio no utiliza especificaciones de excepción. Esto es Boost, que es algo así como el niño poster para hacer cosas raras y útiles con partes avanzadas del lenguaje.

1

Citando A Pragmatic Look at Exception Specifications:

(Mis) entendimientos

La segunda cuestión tiene que ver con saber lo que está recibiendo. Como muchos personas notables, incluyendo los autores de la excepción Boost especificación razón de ser, lo han puesto, programadores tienden a usar excepción especificaciones, como si se comportaban la forma en que el programador le gustaría, en lugar de la forma en que realmente hacen comportarse.

Esto es lo que mucha gente piensa que las especificaciones de excepción hacen:

Garantía
  • que funciona sólo lanzar excepciones enumeradas (posiblemente ninguno).

  • Habilitar optimizaciones del compilador basado en el conocimiento que sólo aparece excepciones (posiblemente ninguno) será lanzados.

Las expectativas anteriores son, de nuevo, engañosamente cerca de ser correcta.

Consulte el enlace para obtener más información.