[basic-improvements] try/finally support for c/c++
Richard Henderson
rth@redhat.com
Tue Nov 5 15:57:00 GMT 2002
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~
More information about the Gcc-patches
mailing list