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

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

On Thu, Sep 12, 2002 at 08:50:15PM +0200, Karim BELABAS wrote:
> > Yes, I think the second interface is much better (with minor changes...).
> 
> So in fact, you'd completely remove the CATCH_ALL / numer parameter ?

As you saw it yourself, it is too tempting to use.  ;-)

I think you saw with my example of macroization that it provides no
real advantage, but if you use it, it is a lot of work to rewrite it
when another err needs trapping...

> Hum. Any other opinion ?

Hmm, to make things even cleaner:

  long err_no;

  BEGIN_ERR_CATCH_TO(err) { Code...
  } END_ERR_CATCH

  if (err && err != this_err)
     ERR_PROPAGATE(err);

(local variable used, *and* things do not mix with C++ exceptions).

> >> 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?
> 
> What do you mean ? I don't see what extra stuff you'd catch with your
> proposed mechanism [ assuming pari_errno is available in both ].

To add another error to catch, replace

  if (err && err != this_err)

by

  if (err && err != this_err && err != that_err)

(or use switch(); or use whatever construct one finds convenient for
the situation).
 
> Traditionnal visual representation for catch/throw mechanisms is something
> like
> 
>   Try {
>     /* code */
>   }
> 
>   Catch (err) {
>     /* recovery */
>   }

You mean C++ when you say "Traditional"?  I do not consider this as an
acceptable example to copy...

> > trap() does not count - the semantic is too ugly.
> 
> What would you propose ? I have changed slightly the behaviour of trap()
> under GP in 2.2.4 [ it shouldn't change a thing for people currently using it ]
> and documented in detail _under GP_ as it currently stands.

If the documentation is as it was 2 months ago, it is IMO
incomprehencible.  OK, I checked the CVS's short-help of 2 weeks ago,
and it still is.  What is bad with

 error = trap( seq )

?  If you need the result of the seq, just do

 error = trap( seq1; result=statement )

[And I would feel better if the high-level break-loop interface is
moved to a different function - and the documentation rewritten.
"Commands read", "as if nothing had happened" etc are very
confusing...]

> That's section 2.7 (Errors & error recovery) of the manual (from CVS...).
> Please check it out, and give suggestions for improvement !

With the exception of break-loop, the long doc is acceptable (if one
wants the current interface).

Hope this helps,
Ilya