[pypy-dev] Re: [pypy-svn] r8078 - pypy/trunk/src/pypy/interpreter

[holger krekel]

On Fri, Jan 07, 2005 at 18:09 +0000, Armin Rigo wrote:
> On Fri, Jan 07, 2005 at 12:39:41PM +0100, holger krekel wrote:
> > > Log:
> > > changed LOAD_GLOBAL to support the flow space better.
> > > In case of a NameError, where the space does not define NameError,
> > > we raise a real NameError with a message.
> > 
> > (...).  It seems the flow
> > object space could easily provide its own w_NameError and
> > then you can check the usual way, catching an OperationError and 
> > then for e.match(space, space.w_NameError) without changing 
> > the interpreter. 
> 
> I guess the goal is to have the problem crash the program with a meaningful
> error message.  If the flow objspace provided a w_NameError, then it would
> become a normal exception within the flow graph, and you would end up
> compiling a program that contains an explicit "raise NameError".  In this case
> it's better just to crash the flow objspace clearly.

Probably, it depends on the exact context.  

But forgetting about this detail, I don't yet see the point of
throwing a NameError instead of an AttributeError here with a
slightly modified message.  I mean if you see the lines like

   ...
   w_exc_type = f.space.w_NameError
   AtttributeError: 'FlowObjSpace' object has no attribute 'w_NameError'

you'll now see (approximately): 

   ... 
   raise NameError, (message +
                        ", but %s has no NameError!" % f.space)
   NameError: global name w_NameError is not defined, but FlowObjSpace 
              has no NameError! 

why is the latter more helpful? 
 
> Maybe a nicer hack than Christian's can be found for this purpose, e.g.  
> setting w_NameError to a special value that would trigger an (interp-level)  
> AssertionError in the constructor of OperationError -- the advantage is that
> the AssertionError can provide the meaningful bit of information: the intended
> message of the faulty w_NameError.

Makes sense.   

cheers, 

    holger