find_name doesn't obey docs on unbound

[Perry Wagle]

Looking at the source I saw that the code doesn't even try to throw the exception.  And its commented as being broken with respect to scanning through all the namespaces.  And its for only one of the many ways to get bindings of variables.  I don't think I know them all, nor do I understand how all namespaces are used in practice.

In this case, in my very INcomplete grepping about, I got the impression that the whole errorson thing with flags to specify when and when not to throw errors is all there, but was largely ignored.

Hence, my judgement was that whoever went through and added all the (optional) error generation needed to write the tests, since they would know what had been decided about what all should do what when and where.

That is, I think perl is "lax" about letting vars be unbound, and python is very very picky.  If you are trying to implement both, then I think you want more of a policy specification than a simple on/off flag.

-- Perry


On Feb 16, 2010, at 9:43 AM, Jonathan Leto wrote:

> Howdy,
> 
> Can you provide a small snippet of code that reproduces this problem?
> I can add it as a test case and it will have a much better chance of
> being fixed and staying that way.
> 
> Duke
> 
> 
> 
> On Mon, Feb 15, 2010 at 5:15 PM, Perry Wagle <wagle at mac.com> wrote:
>> find_name (ie, Parrot_find_name_op()) doesn't have a code path to throw an exception if the name is not bound.  It just returns NULL.
>> 
>> I was invited to repair that, but if I did, all the code that depending on the default behavior not being as documented (its supposed to throw an exception on unbound) would now barf.  I expect that to be a lot.
>> 
>> How should that be handled?
>> 
>> -- Perry
>> 
>> PS.  The code also says it doesn't crawl the scopes completely either.
>> 
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>> 
> 
> 
> 
> -- 
> Jonathan "Duke" Leto
> jonathan at leto.net
> http://leto.net