Andrew Maltsev ([EMAIL PROTECTED]) wrote:
> More on that problem. The problem is that when a test is executed in
> eval next thing done is:
> my $exception=$@;
> ...
> if($exception) {...}
>
> And the trick is that Error.pm uses `overload' and in that case it would
> return 0, which does not evaluate to `true' in if($exception)!!! It is
> probably a bad design decision on behalf of Error.pm author, but still..
It is indeed a bad decision. I already sent him a patch quite a while
ago but have had no response yet. I'll attach the email I sent.
> The fix is to change the above code to:
>
> if(ref($exception) || length($exception)) { ... }
I think
if ("$exception") {
works too.
> P.S. Is there anybody alive in that list? I've got no responce so far..
Give us a chance! I've only had time to sleep since I last checked
the list :-)
>From [EMAIL PROTECTED] Tue Feb 13 20:09:17 2001
Date: Tue, 13 Feb 2001 20:09:17 +0000
From: Adam Spiers <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: boolean overloading in Error.pm
Message-ID: <[EMAIL PROTECTED]>
Reply-To: Adam Spiers <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
X-Home-Page: http://www.new.ox.ac.uk/~adam/
X-OS: RedHat Linux
Status: RO
Content-Length: 1814
Lines: 50
Hi Graham,
Many thanks for your excellent Error.pm. I recently discovered it,
and have found it to be a great tool for improving my code. Can I
suggest a patch which gives safer behaviour when an exception is
evaluated in a boolean context? The patch is a one-liner, and follows
below. The motivation? Consider the following code:
eval {
do_something_risky();
};
my $exception = $@;
if ($exception) {
handle_exception();
}
where do_something_risky() raises an exception which is an instance
derived from Error.pm. Currently, in the absence of bool overloading,
the numeric conversion overload method Error::value() kicks in, so if
-value is unset, handle_exception() never gets run, which is a
dangerously unpredictable consequence.
You may well ask "Why on earth are you catching Error.pm exceptions
with eval() not try()?" ... The answer is that I'm working with
PerlUnit, a Perl port of the XP JUnit testing framework, which wraps
test code in an eval {}. I also believe that there are other
situations in which the above confusing behaviour could arise, and
that it would be very nice if uncaught Error.pm exceptions would
behave exactly in the same way as normal die() exceptions.
Here's the patch:
--- Error.pm.orig Tue Feb 13 20:03:18 2001
+++ Error.pm Tue Feb 13 20:03:06 2001
@@ -20,6 +20,7 @@
use overload (
'""' => 'stringify',
'0+' => 'value',
+ 'bool' => sub { 1 },
'fallback' => 1
);
If you want a test for it, just ask ;-)
--
Adam Spiers -=- musician & hacker -=- [EMAIL PROTECTED] -=- http://tigerpig.org/
echo '$_=bless[q]]],q;_;;sub s;{local$_=shift;push@$_,++$0,pop(@$_).$s;;$_}($,
=eval((join"\$_->[",qw)Just Another Perl Hacker)).q)$_->[1]]]])))=~s~((?<=.(?{
++$*})))?_::~$*&&$"~egx,print""=>""=>'|perl -ln0e';s;s\;;_::AUTOLOAD$1;g;eval'
