Re: [PyX-devel] Curves with infinite curvature

[Joerg L. <jo...@us...>]

Hi,

On 14.09.05, Andre Wobst wrote:
> 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.

In the framework of our present implementation it would be easy to put
the parameter value leading to the problem in the exception. This has
the drawback that when the caller has passed a list, he doesn't know the
index in the list, which is suboptimal. On the other hand, we could
capture the exception in the method decorator. There we still know the
list index, which we could use to generate a new exception containing
this information. Then the caller would get all the information he
needs. 

> - 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)
> 

I don't like this idea too much. The main thing which bothers me, that
we somehow mask an error, which actually has occured. In this sense,
this is totally different from the _invalidcurrentpoint example. There
is one argument in favour of it, namely the existence of NaN in many
floating point implementations. This would set a precedence for a
similar solution in PyX.

> - 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.

This gets a definite -1 from me, as it strikes me as being totally
unpythonic.

> 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 ...

No. Internally, we should no how to deal with our markers. There is
really no need to protect us from ourselves.

All in all, I would still favour the first option, as long as there are
not more arguments against it. Alternatively, you can try to convince me
of the merits of the second solution :-)

        Jörg