#!/usr/local/bin/perl -w
use strict;
use Carp;
foo();
print "done\n";
sub foo {
eval {
bar();
};
print 'In foo(), following eval ... $@', " = $@\n";
}
sub bar {
croak "croaking in bar()\n";
}
Clearly the intent is that foo() wants to handle the case of bar()
failing. Yet, this program produces the output:
In foo(), following eval ... $@ = croaking in bar()
at ./err2 line 17
main::bar() called at ./err2 line 11
eval {...} called at ./err2 line 10
main::foo() called at ./err2 line 6
done
Is there a way to suppress the output of croak? Clearly this is a
situation where I want to handle the failure myself, and not show this
croak output to the enduser.
Since you are using eval when there is a call to bar() you know there
is some error when $@ is set. If you want to handle yourself then you
can die or do what ever if $@ is set. Does this answer your question
or you are expecting something else ?
What output do you get if you DON'T have the print in foo()?
BugBear
In this case, there is no output of croak. Due to the eval, croak stuffs a
message into $@. You print the contents of $@.
> Clearly this is a
> situation where I want to handle the failure myself, and not show this
> croak output to the enduser.
If you don't want the contents of $@ printed, then don't do print it. It
doesn't get much simpler than that!
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
OOPS! Operator error.
Thanks all.
> OOPS! Operator error.
You may have been confused by the behaviour of the debugger. I find
that if you are stepping through code and croak is called from within
eval then the debugger just continues until the next breakpoint (or
the end of the script, whichever is sooner). I suspect this is due to
croak manipulating the stack though I haven't looked into it. Setting
a breakpoint on the next line works around the issue.
Andrew