I ran into a potential problem when writing some code this weekend.
I'm running a network socket to pick up data and then run it against a
database connection before I return the response. Essentially it falls
into a few steps:
read from network
read from database
write to database
do something else on network
write to network
Being the cautious code writer I thought it would make sense to use
something like:
eval{
alarm(10);
"read from network"
"read from database"
....
}
But each of these database calls has it's own eval{} around the database
query (as an example):
my $rv;
eval {
$rv = $dbh->do($sql) or die $!;
};
if ( $@) {
die "[EMAIL PROTECTED]"
} else {
return $rv;
}
Which essentially means if I flattened out all the subroutines I would
end up with something like
eval {
...
eval {....}
if ($@) { }
eval { ... }
if ($@) {...}
}
if ($@) {
.....}
The problem I run into is throwing the exceptions up to the top eval{}
structure when I need to communicate that something didn't work right
so I can provide feedback to the network client connection.
I suppose I could try and rewrite the code to un-nest the eval{}
statements but I think that is avoiding learning something I should know
about how to manage eval{} for block exception handling.
Is there some way to rethrow or propogate errors or some tips on how to
manage this better?
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
