Re: Broken exception handling in gp_read_str()

[Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>]

On Thu, May 21, 2009 at 05:59:33AM +0200, Lorenz Minder wrote:
> Hi,
> 
> BA:
> > On Thu, May 14, 2009 at 04:11:13AM +0200, Lorenz Minder wrote:
> > > I can't seem to catch errors of gp_read_str() with the TRY / CATCH
> > > mechanism anymore.  I don't know when this broke, but it worked in PARI
> > > 2.4.2 and earlier.
> > 
> > Actually, catching runtime errors work, but not syntax errors, this is
> > the change below:
> > 2.4.3C12- syntax errors, SIGINT and "PARI bugs" are no longer trapped
> > 
> > The whole TRY / CATCH facility need to be improved, see bug
> > http://pari.math.u-bordeaux.fr/Bugs/329
> 
> Thanks for these references.
> 
> I'm not completely sure if that is a temporary change, or if the syntax
> errors will never be trapped any more?

This is a temporary bug necessary to make the new breakloop usable.
No one want to enter a breakloop after a syntax error.
This also fix some totally broken behaviour from gequal.

>  If the latter, how do I make sure
> my program does not terminate if I give a wrong string to gp_read_str()?

You must install your own PARI error handler.

> My issue is that I'm binding the PARI functionality into Python via a
> module which sometimes calls gp_read_str() with user supplied data.
> Crashing the Python interpreter for a user error is of course a rather
> serious problem.  For versions <= 2.4.2 I could catch the error and
> throw a Python exception instead.

Using your own PARI error handler is going to be much safer than using trap.
Do something like

#include <pari/paripriv.h>
...

  if (setjmp(GP_DATA->env))
    z = NULL;
  else 
    z = gp_read_str(str)
  if (!z) fprintf(stderr,"error in PARI");

> How can I restore that functionality with newer PARI versions?

You cannot in GP. In extreme case you can use default(recover,1) but
that terminate GP.

Now the plan for GP is:
1) clearly separate "errors" from "events".
2) add a function iferr(code,errbranch,{noerrbranch}) which work as follow:
 2.1) code is executed.
 2.2) if no error occurs and the optional argument {noerrbranch} is
      present evaluated it (as if() do).

 2.3) if an error occurs, set the local lexical variable "err" to the error
      data and evaluated the argument errbranch. errbranch can inspect the
      variable err and propagate the error further by doing error(err).
3) Change trap to be a general event handler, and reinstate the lost
functionalities.
4) Change the compiler to return NULL for invalid input. This would make
handling syntax error much easier.

Cheers,
Bill.