Re: introspection on errors

[email protected] (Aamer Akhter) Fri, 11 Jun 2004 15:24:43 -0400
Newsgroups perl.recdescent
Message-ID <[email protected]>
On Jun 11, 2004, at 2:08 PM, Ron D. Smith wrote:

> On Friday, Jun 11, 2004 Aamer Akhter said:
>
>>
>> On Jun 11, 2004, at 11:49 AM, Ron D. Smith wrote:
>>
>>> On Friday, Jun 11, 2004 Aamer Akhter said:
>>>> Hello,
>>>>
>>>>   Is there a way to detect that prd ran into an error?
>>>
>>> The answer to your question is so obvious that I suspect you are 
>>> either
>>> really asking a different question or that "I don't get it".
>>
>> I may not have explained properly. Here is an example of the error I
>> was getting:
>>
>>       ERROR (line 123): Untranslatable item encountered: ".*?)\n/"
>>                  (Hint: Set $::RD_HINT (or -RD_HINT if you're using
>> "perl -s")
>>                         for hints on fixing these problems.)
>>
>> But Parse::RecDescent definitely returns something:
>>
>>      use Data::Dumper; print Dumper 
>> (Parse::RecDescent->new($grammar));
>> exit
>>
>> gives me:
>>
>> $VAR1 = bless( {
>>                   '_AUTOTREE' => undef,
>>                   'localvars' => '',
>>                   'startcode' => '',
>>                   '_check' => {
>>                                 'thisoffset' => '',
>>                                 'itempos' => '',
>>                                 'prevoffset' => '',
>>                                 'prevline' => '',
>>                                 'prevcolumn' => '',
>>                                 'thiscolumn' => ''
>>
>>
>> should this case have returned a undef instead?
>
> Um, I'm not sure, actually.  I would have thought so but I have never 
> had to
> code a script where I anticipated failure AS A NORMAL OPERATION.  (In 
> other
> words, I have had lots of problems in debug, but once it worked, it 
> just
> worked...)
>
> Perhaps it has something to do with the fact that you are using 
> autotree.
>
> Can you supply a simple test case?  Its hard to see what might be 
> happening
> based on the extracted snippets from above.

ok i did some playing around it appears to be related to the difference 
between these two grammars:

1 (fails to provide undef)
=====
Q:  classQueueLimits
     QUEUECOUNTER'S  '/'


classDropRate: /(drop rate.*?)\n/ {$return=$1}

matchLine:    classCounters(?)
======



2 (provides undef, matchLine rule removed)
======
Q:  classQueueLimits
     QUEUECOUNTER'S  '/'


classDropRate: /(drop rate.*?)\n/ {$return=$1}
======

If I remove the '/' in Q: I also get an undef.

I do have autoaction, which is defined as:

$::RD_AUTOACTION = q{
     if ($#item==1 && (ref $item[1] ne 'ARRAY')) {
	#if only one item, and is either a terminal or an array
	$return = $item[1];
     } else {
	foreach my $i (keys %item) {
	    if ($i=~ s/(\([\?s]{1,2}\))$//o) {
		$item{$i} = \@{$item{$i.$1}};
		delete $item{$i.$1};
	    }
	}
	$return = bless \%item, $item[0];
     }
};

Not defining autoaction doesn't seem to affect the behavior.




>
> Perhaps one of the Gurus can weigh in?

cc'ing back the list

>
>> -- 
>> Aamer Akhter / [email protected]
>> NSITE cisco Systems
>
> --
>  Intel, Corp.
>  5000 W. Chandler Blvd.
>  Chandler, AZ 85226
>
> -- 
>  Intel, Corp.
>  5000 W. Chandler Blvd.
>  Chandler, AZ  85226
>
>
>

-- 
Aamer Akhter / [email protected]
NSITE cisco Systems