Re^2: Maypole and I - Tales from the Frontier of a Relationship

I haven't delved into the depths of Apache::Registry and Maypole to determine where the errors get eaten and not reraised. I believe that the reason are unchecked eval-block expressions, but I can't offer any hard facts for that assumption.

Comment on Re^2: Maypole and I - Tales from the Frontier of a Relationship

Replies are listed 'Best First'.
Re^3: Maypole and I - Tales from the Frontier of a Relationship by diotalevi (Canon) on Sep 08, 2004 at 13:07 UTC
Would you care to write a Devel::UncheckedEvalBlock ala Initial Devel::UncheckedOps, a macro for perl and <rant>CPAN modules failing to check for write errors</rant>? It'd just be the example assuming there was some sort of magic in those hashes to generate some regexp code over a hypothetical stringification of an optree and that changing the stringified optree would change the actual optree... `$optree =~ s( (?<= $STATEMENT{ $CONTAINS{ $OP_ENTERTRY } } ) (?! $OP_NEXTSTATEMENT $STATEMENT{ $CONTAINS{ $GVSV{ '*@' } } } ) ) { warn $@ if $@; }xg` [download]	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Maypole and I - Tales from the Frontier of a Relationship
by diotalevi (Canon) on Sep 08, 2004 at 13:07 UTC

Would you care to write a Devel::UncheckedEvalBlock ala Initial Devel::UncheckedOps, a macro for perl and <rant>CPAN modules failing to check for write errors</rant>? It'd just be the example assuming there was some sort of magic in those hashes to generate some regexp code over a hypothetical stringification of an optree and that changing the stringified optree would change the actual optree...

$optree =~
    s(
        (?<= $STATEMENT{ $CONTAINS{ $OP_ENTERTRY } } )
        (?! $OP_NEXTSTATEMENT
            $STATEMENT{ $CONTAINS{ $GVSV{ '*@' } } } )
    )
    {
        warn $@ if $@;
    }xg
[download]

[reply]
[d/l]