Bill Allombert on Wed, 12 Mar 2003 16:35:28 +0100


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

trap()ing user errors


Hello PARI-Dev,

It seems that currently trap() cannot catch user error raised with
error(). It could be useful to add that. Also it would not
cost much to support all the errors reported by PARI or at least
a 'none of the above' error code. 

Beside I do not like the syntax/semantic of trap:
Trap currently has two very different use:
1) Install an error handler. 
2) Execute an instruction in error recovery mode.

I would prefer that the second usage be covered by a 
iferr(SEQ,REC{,error})
so that trap() will not need a third parameter anymore.

What is lacking to trap, in my opinion:
1) REC is not provided with error code/error message
2) We cannot trap 'everything but that error'.
3) No GP2C support.

Fix 1) would probably fix 2 also.

As a general note, I think it better if functions return errors
as part of their output whenever is convenient, instead of raising
an error. This ask for more work of the caller, but this avoid 
relying on trap when error catching is needed.

For example, sqrtn(Mod(a,p),3) raise an error id a is not a cube mod p.
Unfortunately testing if it is take almost the same time that doing
the computation so it is a waste to have to write 
if(Mod(a,p)^((p-1)/3)!=1,next); sqrtn(Mod(a,p),3)
if we want to avoid using trap.

Cheers,
Bill.