XML documents have a very strictly defined format. All conforming parsers will throw an exception for the input you describe, because the input is not XML and the "correct" thing to do is to reject the whole input file.

This makes sense when you use XML to transfer data between systems - you generally don't know much about the sending system, and if the input doesn't conform to the specs, the right attitude to take is that the other system has just thrown a bug or the stream has been mangled during transfer.

Again; your input is not XML. Trying to subvert the XML specs is fine by me, but you should not expect any standard XML tools to help you do it, and other developers/spec-writers will probably not understand all the subtleties involved. The full XML spec really is not as easy as you'd think from reading a couple of XML files. If you're diverting from it, you'd better make really sure you know what you're doing.

fair. It's a headless app sitting on a remote box. I need to know if it's getting an error (dies to a function that shoots me a note). Not subverting, just doing better error handling to know if something bad this way came-ith.

I was pretty tired when I posted that note.

After re-reading your post, I see I misread your intent. I'll let my note above stand just in case anyone wants to try to "ignore" un-xml constructs.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

my $value;
eval {
    $value = $record1->getAttribute('value1');
};
next FILE if ( $@ );
[download]

Note the scope. Define the variable outside the eval, or you'll only be able to use it in the block.

Phil

Note that the eval will catch all errors, not just this one. It might be prudent to look at the contents of $@ (see perlvar) to see if the error you caught is really the one you want to skip silently.

my $value;
eval {
    $value = $record1->getAttribute('value1');
};
if ( $@ ) {
    next FILE if ( $@ =~ /^duplicate attribute/ );
    die $@;
}
[download]