Finding out the String-based Exceptions for a Module?

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.
 
B

Ben Morrow

Quoth "Veli-Pekka Tatila said:
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?

You don't, unless it's in the module's documentation. There's no
shortcut.
Which reminds me, for quite some time I've been wondering why there's no
Perl module to parse Perl
PPI.pm

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.

Parsing Perl correctly without evaluating it (i.e. without running at
least some of the code) is impossible. Consider source filters as a
degenerate case: it's completely impossible to parse the rest of a file
after a 'use' line that installs a source filter without running the
source filter.

PPI does an excellent job for any 'reasonably sane' Perl code. :)

Ben
 
V

Veli-Pekka Tätilä

Ben said:
You don't, unless it's in the module's documentation.
Ah I see. Often I've thought of just looking at the module code but the
messages might change in the next release, so that's asking for trouble
sooner or later said:
There's no shortcut.
Ah, thanks for a clear and concise answer once again. Dealing with source
filters is an enlightening example.
PPI.pm <snip>
PPI does an excellent job for any 'reasonably sane' Perl code. :)
Ah, this is new stuff to me. I took a cursory glance at the docs and they
look good. I found the Windows PPM package here:

<http://www.bribes.org/perl/ppmdir.html>

Finally, here are interesting quotes to people not knowing this module:

Quote:
Even perl itself never really fully understands the structure of the source
code after and indeed as it processes it, and in that sense doesn't "parse"
Perl source into anything remotely like a structured document. This makes it
of no real use for any task that needs to treat the source code as a
document, and do so reliably and robustly.

The purpose of PPI is not to parse Perl Code, but to parse Perl Documents.
By treating the problem this way, we are able to parse a single file
containing Perl source code "isolated" from any other resources, such as
libraries upon which the code may depend, and without needing to run an
instance of perl alongside or inside the parser.

[success rate] PPI has succeeded in this goal far beyond the expectations of
even the author. At time of writing there are only 28 non-Acme Perl modules
in CPAN that PPI is incapable of parsing.
End quote.

I also saw this Randal Schwartz article on the subject:

<http://www.perlmonks.org/index.pl?node_id=44722>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top