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

[Richard Henderson <rth at redhat dot com>]

On Tue, Nov 05, 2002 at 03:19:02PM -0800, Aldy Hernandez wrote:
> +   /* Currently we only support cleanups for C.  */
> +   if (actions != _UA_CLEANUP_PHASE)
> +     return _URC_CONTINUE_UNWIND;

IIRC, Jakub already pointed out that actions is a bit mask.
Should be

	if (!(actions & _UA_CLEANUP_PHASE))

> +         try-finally-statement:
> +            @b{__try}
> +                 @b{@{} block-item-list @b{@}}
> +            @b{__finally}
> +                 @b{@{} block-item-list @b{@}}

The braces should not be required.  This should be 

	@b{__try}
	  @i{statement}
	@b{__finally}
	  @i{statement}

and, indeed, we should have a test for

	__try
	  q = 1;
	__finally
	  x = 2;

or something.

Hmm.  I see that C++ *does* require the braces.
In which case you should use compound-statment instead of
calling block-item-list directly.

> + The @code{__try} block is executed.  After the __try block exits,
> + control is transferred to the @code{__finally} block regardless of how
> + the __try block exits.

This implies that longjmp is try/finally aware, which is false.

Probably should have text similar to C++ 15/2, such that you 
can't goto into a try handler.  (I think that breaks with sjlj
exceptions.)

> + @node C++98 Try-Finally Edits
> + @subsection ISO/IEC 14882:1998 Edits for Try-Finally
> + 
> + @itemize @bullet
> + @item
> + @cite{2.11 Keywords: Table 3}
> + 
> + Add @code{__finally}.
> + Add @code{finally}.

"finally" is not a keyword.

> + @cite{15  Exception handling}
> + 
> + Rename the @code{handler-seq} production by the following:
> + 
> + @example
> +         handler-seq:
> +                 handler-seq-catch finally-block
> + 
> +         handler-seq-catch:
> +                 handler handler-seq-catch
> + 
> +         finally-block:
> +                 @b{__finally} compound-statement
> + @end example

This says __finally is required.  Which is false.  Also doesn't
indicate that __finally can be used without catch.

Should probabably mention that 

	try {
	  A;
	} catch (...) {
	  B;
	} __finally {
	  C;
	}

is equivalent to 

	try {
	  try {
	    A;
	  } catch (...) {
	    B;
	  }
	} __finally {
	  C;
	}

> + Add new text at the end of section 2.
> + 
> + @quotation
> + Before control is transferred to the desired destination, the
> + __finally block is executed.  After such block is executed, control is
> + transferred to the desired destination.
> + @end quotation

There's got to be a better way to say this...  Dunno what though.

> + @cite{15.1  Throwing an exception}
> + 
> + Add new section before section 2 and 3.
> + 
> + @quotation
> + After an exception is caught by an applicable handler (if present),
> + but before control is transferred elsewhere (provided the program does
> + not exit), the code in the __finally block is executed.
> + @end quotation

This isn't needed if you define try/finally correctly elsewhere.

> + @cite{15.2  Constructors and destructors}
> + 
> + Add new text to section 3.
> + 
> + @quotation
> + If code within a @i{try} block (or within code called from a try
> + block) causes an exception that is not caught by the subsequent
> + @i{catch} blocks, the code in @i{__finally} executes as the stack
> + unwinds upwards.
> + @end quotation

"Upwards" is bad language.  See the existing language that
uses "path".

You probably need to define __finally in terms of destructors
in order for this to work out properly.  E.g. a finally block
is the destructor for an anonymous object of an anonymous type.
Or something.  Perhaps Jason or Mark could help here?


r~