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

[Ilya Zakharevich <ilya@Math.Berkeley.EDU>]

On Thu, Sep 12, 2002 at 12:36:03AM +0200, Karim BELABAS wrote:
> > >   CATCH(numerr) {
> >
> > I do not think the situation with one trap to catch is frequent enough
> > to make this interface useful.
> 
> Please elaborate. I'm note sure I understand your point. You'd rather have a
> general CATCH(CATCH_ALL), and no specific error number ?

> Well, if I only want to catch "precision error in truncation", I'd rather have
> 
>   CATCH(precer) { ...; }
> 
> than
> 
>   CATCH(CATCH_ALL) {
>     CATCH_RELEASE();
>     switch (pari_errno) {
>       case precer: ...; break;
>       default: THROW(pari_errno);
>     }
>   }

Yes, I think the second interface is much better (with minor changes...).  Too many things hidden under the hood with the first interface.

    EXECUTE_CATCHING {
      some code
    } END_EXECUTE_CATCHING

    if (pari_errno != precer)
	THROW(pari_errno);

> and have to propagate everything I get and don't like. I don't see any point
> in complicating the interface, granted that both forms are available at
> essentially no extra cost.

IMO, your interface is more complicated.  Complication is not in the
number of keystrokes, but in the distance between the "visual
representation" and the flow direction and the intent of the programmer.

> It already occurs naturally 6 times in the library (+ 1 to define trap()).

trap() does not count - the semantic is too ugly.

> In most cases we want to catch a specific error ( Exception: gegal and the
> pipe testing code ).

Today.  What if tomorrow you find another stuff to catch?

Ilya