V
Veli-Pekka Tatila
Hi,
A quick q on Perl exceptions. I've noticed that most modules don't support
Perl's exception objects with the PROPAGATE method but in stead carp or
worse might die with a string-based exception, if you will. To catch the
string-based variety, whose only state are the string contents, one must
use an eval block and match against $@ appropriately.
Now my question is, how do I know which strings to match on error and what
components they are made up of? One could draw a comparison to the name of
an exception class and its methods on offer. Many modules document their
error messages very vaguely saying that it might just carp or die. The
obvious non-lazy solution would be to look in the module code and then
manually pull apart any components in that string in which you might be
interested, say using regexp matching and homing in at variable interpolated
parts.
But is there a lazier way out there. That is might there be a module that
can analyse the carp or die messages on a per function or method basis say
print them out or better yet suggest regexpes for matching interesting bits?
I know It sounds hard and a bit vague at this point, but something like that
came to mind.
Which reminds me, for quite some time I've been wondering why there's no
Perl module to parse Perl in a structured way splitting it into some sort of
parse tree you could walk programmatically or using a set of callbacks much
like a SAX parser would. Well, Perl is hugely more complex than say HTMl and
such parsing, especially if implemented as a pure Perl solution, would be
very slow and huge in size. Most filtering scripts tend to attack
understanding Perl as a problem in regexp matching that might ultimately
fail. But couldn't the interpreter help here as it surely knows how to parse
a evaluated string of Perl on the fly? I guess I'm missing something very
essential here.
A quick q on Perl exceptions. I've noticed that most modules don't support
Perl's exception objects with the PROPAGATE method but in stead carp or
worse might die with a string-based exception, if you will. To catch the
string-based variety, whose only state are the string contents, one must
use an eval block and match against $@ appropriately.
Now my question is, how do I know which strings to match on error and what
components they are made up of? One could draw a comparison to the name of
an exception class and its methods on offer. Many modules document their
error messages very vaguely saying that it might just carp or die. The
obvious non-lazy solution would be to look in the module code and then
manually pull apart any components in that string in which you might be
interested, say using regexp matching and homing in at variable interpolated
parts.
But is there a lazier way out there. That is might there be a module that
can analyse the carp or die messages on a per function or method basis say
print them out or better yet suggest regexpes for matching interesting bits?
I know It sounds hard and a bit vague at this point, but something like that
came to mind.
Which reminds me, for quite some time I've been wondering why there's no
Perl module to parse Perl in a structured way splitting it into some sort of
parse tree you could walk programmatically or using a set of callbacks much
like a SAX parser would. Well, Perl is hugely more complex than say HTMl and
such parsing, especially if implemented as a pure Perl solution, would be
very slow and huge in size. Most filtering scripts tend to attack
understanding Perl as a problem in regexp matching that might ultimately
fail. But couldn't the interpreter help here as it surely knows how to parse
a evaluated string of Perl on the fly? I guess I'm missing something very
essential here.