Perl - error handling

Gidday all,

Im not as experienced in Perl as I 'd like to be,

attached is an inline script that I wrote that is called from my secondary nav dct to return all the items from the primary nav dct so that a user is able to associate a secondary nav menu with a primary nav item. It returns an option selection list.

I know where to trap the erros but not what to do if it encounters an error, ie how to make it fall over gracefully,

ie,
1) what to do if it can't find the primary nav dcr?

Any help appreciated.
Thank you
Colin

Find more posts tagged with

Comments

gzevin

you decide what do you want to do. you might decide to output a HTML snippet, or write to a log file

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

How do you define "fall over gracefully"? If you already know how to capture the errors, then you can just use an IF statement, for instance. This very simple code is an example:


$string = "some unexpected value returned from another subroutine";
if ($string =~ /^expected value$/) {
    print "Yeah, we made it!";
} else {
    print "We've encountered an unexpected value";
}

I know, crappy example -- but is that what you're asking?

Dave

tsrookie

Dave,

Thanks but sorry I can't have been clear enough. Its a script that is run by the dct as an inline callout that parses our primary nav dcr and returns the xml to build a drop down list of all the primary nav items for selection by the user. see code below. I am using if statements but the issue is that inline scripts must return properly formatted xml to the dct. The only option may be to write the error out to a logfile.

falling over gracefully- If for example the primary nav dcr that I wish to parse doesn't exist, when you attempt to open the dcr TS just comes back and says it can't open ... I guess I'd rather it say unable to locate primary nav dcr, have you forgotten to create it? or other customised error messages.

Regards
Colin

#!/web/Interwoven/TeamSite/iw-perl/bin

# for docuenetation on the following modules see http://iwhome/iw/help/tst/pt/

use TeamSite: Smiley Very Happy

CRparser;
use TeamSite: Smiley Very Happy

CRnode;

my $waPath = $ENV{IW_WORKAREA};

$waPath =~ s!//weaver!/.iwmnt!;

my $dcrPath = qq[$waPath/templatedata/navigation/primaryMenu/data/primarymenu];

my $optionItems;

if ( ! open( FILE, $dcrPath ) ){

# error handling
print "Unable to open DCR: $dcrPath<br />";

}
else{

local $/;
$xml_string = <FILE>;
close(FILE);

}

if ( $xml_string eq "" ) {

print "!! Error: Unable to getDCR $dcrPath <br />";

}
else{

my $parser = TeamSite: Smiley Very Happy

CRparser->new();
my $docnode = $parser->parse($xml_string,'document'); # fetch "document node"

if ( defined ( $docnode ) ){

my $rootnode = TeamSite: Smiley Very Happy

CRnode->new( $xml_string );

# get a list of parent nodes
my @parents = $rootnode->get_node_list();

foreach my $parent ( @parents ){

# foreach parent node get a list of the child nodes
my @nodes = $parent->get_node_list();

my %nodeHash = ();
foreach $node ( @nodes ) {

$nodeHash{ $node->type() } = $node->value();

}

# extract from the node Hash the itemText element
$label = $nodeHash{'itemText'};
$label =~ s!&!and!g;

$value = $label;
$value =~ s!\s!_!g;
$value = lc($value);

# build the option xml
$optionItems .= qq[<option value="$value" label="$label" />\n];

}

}

}

# the following returns a properly formatted xml file to the callout

print <<eof;
<?xml version="1.0" encoding='UTF-8'?>
<substitution>$optionItems</substitution>
eof

Adam Stoller

Here are some miscellaneous thoughts on the matter:

If the code is being used in a workflow externaltask or cgitask script (either directly or as part of a module used by such a script) you generally do not want to exit or die directly from the code - but rather make sure that you return a consistent value
I've done code where '0' indicates success and different non-zero values were used to indicate different types of errors, and I've done code where '1' is "true"/"success" and '0' is "false"/"failure" - either is fine - but document it and try hard not to mix the two ideaologies together.
If the code is subject to reuse for multiple scripts - turn it into a module and again, do not exit or die but either return a value (as above) or set a globally accessible error variable to indicate error (or both)
If the code is part of a directly initiated script and not used as an externaltask or cgitask script, but is used as part of CGI code - include a use CGI::Carp qw(fatalsToBrowser); statement in your code so that any die statement will send its information to the window - it's much easier to debug that way.
You may also want to include use diagnostics; which will cause much more verbose information to be displayed in the case of syntactic errors in the code (useful during development and when making modifications to existing code)
In almost all cases - having a logfile that you can reference for any and all such information (fatal and non-fatal) is a good idea - there are a lot more ideas surrounding this than I care to try to enumerate at this time though.

Hope that helps.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

I think I understand now --

Instead of


qq[$waPath/templatedata/navigation/primaryMenu/data/primarymenu];

could you use a file handle instead, i.e.


open(FILE,"<$dcrPath") || &doGracefulExitRoutine;

I think that accomplishes the graceful error handling you're looking for -- but in general, it's always good to write stuff to a log file anyway.

Dave