Ilya Zakharevich on Wed, 11 Sep 2002 12:57:39 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: error recovery (was Re: gp: series bug)

On Wed, Sep 11, 2002 at 04:56:14AM +0200, Karim BELABAS wrote:
> The error recovery code in libpari is experimental (hence not documented),
> and I've just modified it in CVS a few hours ago, while investigating some of
> Igor's bug reports [ funny you'd ask just now! ].
> I wanted to encapsulate all the code in the library using (something looking
> like) the trap() mechanism. So I defined a set of 3 macros CATCH / TRY /
> ENDCATCH to hide more complicated routines.

Please do not.  trap() is not a mechanism good enough to have it in
two places.  E.g.:

>   CATCH(numerr) {

I do not think the situation with one trap to catch is frequent enough
to make this interface useful.

>     /* recovery */
>   } TRY {
>     /* code */

> IMPORTANT: the code between CATCH / ENDCATCH is _not_ allowed to use any
> direct flow control instruction to jump out of the protected code [ longjmp,
> break, return, goto, etc. ]. It is OK to fool around within the protected
> area. Getting out using the PARI err() function is also allowed [ e.g. if an
> exception is raised from 'code', not caught by this (or a deeper) block ],
> since it also performs the required cleanup.

Typically, one will want to perform cleanups manually is needed to (to
simplify propagation of the trap to wrappers in another
exception-conscious language).

> Note: I could provide another macro, says CATCH_RELEASE(), that you could
> invoke if you insist on getting out [ and would execute the ENDCATCH cleanup
> code ]. It is not needed in pari and I don't think I want it.

So please do.

>   CATCH(-1)


>   {
>     switch (pari_errno)
>     {
>       case primer1: ...

I think this is more useful than the specialized interface above...