Re: [PyX-devel] Curves with infinite curvature

[Andre W. <wo...@us...>]

Hi,

On 12.09.05, Joerg Lehmann wrote:
> On 12.09.05, Joerg Lehmann wrote:
> > On 12.09.05, Michael Schindler wrote:
> > > There is something else that judges against raising an exception, in
> > > favour of the "arbitrary marker value": We calculate curvatures and
> > > rotations ... always for a list of parameter values. If one of them
> > > makes problems, you will never find out which one of them it was and
> > > you cannot do anything against it. The outcome would be that the user
> > > (or the module that uses this feature) has to ask for one
> > > parameter value after the other in a try...except block.
> > 
> > I would say so. We could put this information in the exception instance
> > and probably should do that anyway.
> 
> s/say/not say/

Ok. I think we're in trouble here. An exception doesn't provide us
with a proper recovery strategy. (It's a well known limitation of an
exception system.) There are several ways out.

- We could raise an execption and mark it with further information.
  Still, since we processed an list of values, the whole system is
  complicated and inappropriate. We can raise only an single exception
  and should provide all information we collected. In some sence, the
  exception is a return value containing some results, which we were
  able to get and some error information. It's a no win situation
  compared to using a marker in the result.

- We could return a marker. This marker could be clever in that sence,
  that it raises an exception as soon as it is accessed. (However you
  could do a "x is _marker" check without an excpetion.) It would be
  kind of a late evaluation exception raising similar to what we did
  with the _invalidcurrentpoint in earlier versions of the path system
  (cf.
  http://cvs.sourceforge.net/viewcvs.py/pyx/pyx/pyx/path.py?rev=1.228&view=markup)

- The third solution could be a callback function in case we step into
  an error. In other languages (list, smalltalk) a (more advanced)
  condition system is used in general in favour of excepts, but the
  question is, whether it's that easy to recover from an error by some
  callback/fallback/whatever.

I think the second option is by far the most easiest one for our
use-case of invalid curvatures/transformations etc. We could make it a
general feature of the marker instance we're planing in favor of the
existing helper.nodefault to raise an exception on access. That's by
the way something such a marker is for ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/