2011-08-25 17 views
6

Sé que esto se discutió en otros temas también, lo que estoy preguntando es exactamente el título de esta pregunta.Delphi - try finally block está garantizado por el compilador para ser ejecutado correctamente?

¿Hay tal caso cuando try/finally el finally no se ejecuta?

try 
    //some error here 
finally 
    //code that MUST be executed 
end; 

No estoy hablando acerca de cómo try..except finalmente deben ser utilizados/bloques, sólo estoy preguntando si esto podría suceder.

LE: Aplicación.Terminate/unplug su computadora son casos particulares.

+2

El compilador no ofrece ninguna garantía más allá del fin del mundo, o su PC. Lo que sea primero. Pero en todos los casos en los que importa, es cuando un bloque finalmente puede hacer algo útil, se ejecutará. –

+1

Estaba viendo esta pregunta http://stackoverflow.com/questions/3484353/is-there-such-case-when-in-try-finally-block-the-finally-wont-be-executed - parece que Los desarrolladores de Java no piensan en wormholes/fin del mundo/etc. Debo admitir que los desarrolladores de Delphi tienen el sentido del humor – RBA

+0

no en Win64 aunque –

Respuesta

22

try..finally garantiza que el código en el bloque finally se ejecutará independientemente de cualquier excepción que se produzca en el bloque protegido. Por supuesto, esto no se aplica si el proceso se cancela antes de que el bloque finally pueda ejecutarse, p. por TerminateProcess o desconectando la alimentación. Un bucle sin fin en el bloque protegido también puede evitar que el bloque final se ejecute.

+11

+1 para bucle sin fin. –

+0

+1 para bucle también. –

+15

Un problema relacionado es que no TODOS los códigos finalmente están garantizados. por ejemplo, podrías tener 3 afirmaciones en la sección final, y explotar en la segunda. La tercera declaración no se ejecutará. Un buen ejemplo sería intentar liberar objetos que no fueron asignados. –

4

Si se corta la alimentación (por ejemplo, si desenchufa la computadora y no tiene batería y no está conectada a un UPS), es muy posible que el bloque finally no se ejecute. Un mal funcionamiento importante del sistema operativo o del controlador (como un BSOD) también podría causar esto. Sin embargo, la idea completa con el constructo try..finally es que el bloque finally se debe ejecutar incluso si se genera una excepción (de cualquier tipo) dentro del bloque try. El bloque finally se ejecutará incluso si hay una instrucción exit dentro del bloque try.

+0

+1 por la respuesta. pero está garantizado por el compilador? – RBA

+3

@RBA: ¿Qué, excatly? El compilador no puede garantizar que la computadora anfitriona (hardware/OS/drivers) funcionará correctamente ... Sin embargo, I * do * cree que está 'garantizado' de que el bloque 'finally' se ejecuta si un usual' raise ESomeException.Create (...) 'se golpea dentro de 'try' (y no ocurre nada más, como que la computadora es absorbida por un agujero negro o algo así). –

+2

+1. Daría otro +1 por el ref de "agujero negro". si pudiera. :) –

3

Si su aplicación provoca una excepción DEP (Prevención de ejecución de datos), no creo que Windows le permita continuar. Su proceso será golpeado, sin ejecutar la sección final. Tu proceso simplemente "desaparece". Sin embargo, esto no tiene nada que ver con lo que el compilador hizo o dejó de hacer.

1

Una vez que se ingresa try/finally, el bloque finally se ejecutará antes de que la ejecución abandone el try/finally.

+0

El bloque finally comenzará la ejecución. Solo espero que nada arroje dentro del bloque. –

+0

@henk ¿quién escribe el código que arroja un bloque finally? –

+0

¿te gustaría comprarles una cerveza? –

Cuestiones relacionadas