James William Pye <flaw@rhid.com> writes:
> On 07/28/04:30/3, Tom Lane wrote:
>> Does anyone have a problem with this macro syntax? The try/catch names
>> are stolen from Java, so I'm figuring they won't terribly surprise any
>> modern programmer, but I'm open to different names if anyone has a
>> better idea.
> Sounds good, but perhaps it would be useful for some developers to have
> the macro syntax broken up into smaller pieces, plpythonu does/did this in
> plpython.h(gone now), and I rolled my own based on plpython's in plpy.
Is there any actual functional usefulness to that, or is it just to
avoid having to reorder existing code to fit into the try/catch paradigm?
I would actually prefer to force people to use the try/catch macros, in
the name of code readability and consistent coding style. I had never
felt that I understood the way the plpython error-trapping code was
structured, until I had to go in and examine it in detail to rewrite it
into the try/catch style. I think it's now a lot more legible to the
casual reader, and that's an important goal for Postgres-related code.
> for example:
> #define PG_EXC_DECLARE() sigjmp_buf local_sigjmp_buf
> #define PG_EXC_SAVE() \
> sigjmp_buf *save_exception_stack = PG_exception_stack; \
> ErrorContextCallback *save_context_stack = error_context_stack
> #define PG_EXC_TRAP() (sigsetjmp(local_sigjmp_buf, 1) == 0)
If you're really intent on doing that, you probably can do it no matter
what I say about it ;-). But I find it hardly any improvement over
direct use of the setjmp API.
regards, tom lane