SEO

Hi hackers,

The current usage PG_TRY() looks something like this:

... normal code ...

PG_TRY();
{
... code that might throw ereport(ERROR) ...
}
PG_CATCH();
{
... error recovery code ...
... plus anything that you wish to do even if an error wasn't thrown
....
(because of a PG_RE_THROW possibility)
}
PG_END_TRY();

... do the same thing over again; since either no ERROR or no RE_THROW()
....

... normal code ...

I propose a new constuct, PG_FINALLY. This will help in eliminating code
duplication (hence lesser possibility of errors), and better modularity. It
will also help if someone wishes to call a non-idempotent function in the
now-repeating code.

#define PG_TRY() \
do { \
sigjmp_buf *save_exception_stack = PG_exception_stack; \
ErrorContextCallback *save_context_stack = error_context_stack; \
bool do_re_throw = false; \
sigjmp_buf local_sigjmp_buf; \
if (sigsetjmp(local_sigjmp_buf, 0) == 0) \
{ \
PG_exception_stack = &local_sigjmp_buf

#define PG_CATCH() \
} \
else \
{ \

#define PG_FINALLY() \
} \
{ \
PG_exception_stack = save_exception_stack; \
error_context_stack = save_context_stack

#define PG_END_TRY() \
} \
if (do_re_throw) \
siglongjmp(*PG_exception_stack, 1) \
} while (0)

#define PG_RE_THROW() do_re_throw = true

This would change the semantics to:

... normal code ...

PG_TRY();
{
... code that might throw ereport(ERROR) ...
}
PG_CATCH();
{
... (optional) error recovery code only *and/or* RE_THROW...
}
PG_FINALLY();
{
... do something that you wanted done in any case; ERROR or not ...
}
PG_END_TRY();

... normal code ...

Hope to find buyers.

Best regards,

--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com

"Gurjeet Singh" <singh.gurjeet@gmail.com> writes:
> I propose a new constuct, PG_FINALLY.

I took a look through the existing uses of PG_CATCH, and found that in
the places where there is duplicate code between the normal and error
exits, it's usually just one or two lines. Where it's more than that,
it's intermixed with code that is not duplicate, and so PG_FINALLY
wouldn't help. I don't care to add code to every use of PG_TRY for
such a limited benefit.

To the extent that the compiler is able to recognize and optimize out
the extra code in blocks where do_re_throw is never changed, that
objection loses force --- but in such cases it seems likely that some
compilers would throw a warning, which we don't want.

Lastly, your proposal silently breaks every existing use of PG_TRY by
changing the existing semantics of PG_CATCH. That will certainly not
do. (This is not even counting the bug that the CATCH code would be
executed inside the same setjmp context, so that any elog within the
CATCH code would turn into an infinite loop.)

Possibly it'd make sense to offer PG_FINALLY as a mutually exclusive
alternative to PG_CATCH, rather than trying to allow both to be used
in the same TRY construct. I doubt you've got reasonable semantics
for the combination anyway --- it seems at least as likely that the
common actions would need to be executed before the special error
actions as after.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster