This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [basic-improvements] try/finally support for c/c++


On Wed, Nov 06, 2002 at 12:02:42PM +0100, Michael Matz wrote:
> Hi,
> 
> On Wed, 6 Nov 2002, Jakub Jelinek wrote:
> 
> > If __try block was exited by return, then the function returns after
> > finishing the __finally block (unless inside other __try block), if
> > __try is exited normally, then execution continues after the end
> > of the finally block,
> 
> This would be fairly weird semantic.  If the finally is formulated as a
> destructor of an anonymous object (like Richard suggested) then it should
> be run after the __try block exits, in _whichever_ way it does so.  This
> also makes much more sense to me.  I wouldn't like to have to write:
> 
> __try {
>   if (bla())
>     return;
> }
> __finally {
>   cleanup();
> }
> cleanup();
> 
> just because the __finally block isn't executed sometimes.  It also makes
> the rule quite easy.  The finally is executed after the try block, no
> matter what.

The __finally block is executed in all cases, the question was what is
executed AFTER the __finally block.

__try {
  if (bla())
    return;
}
__finally {
  code1();
}
code2();

will do:
1) if bla() returns non-zero, code1() is called and then the function returns.
2) if bla() returns zero, code1() is called, then code2().
3) if exception is thrown from within bla or forced unwinding, then code1()
   is executed and the stack unwinding continues

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]