Front page | perl.perl5.porters |
Postings from March 2008
Zefram wrote:
> Abigail wrote:
>
>> Inspecting $@ to check whether an eval die()d is wrong. It can
>> trigger both false positives, and false negatives:
>>
>
> By that logic, there is no way at all to determine what exception
> was thrown. It's not a practical approach.
>
That's not correct.
I find Abigail's comment a little surprising given the way that eval{}
and exception handling is documented. I think Abigail may mean "if you
require local $@, then inspecting $@ is wrong, otherwise if you do not
require local $@, I have found in my personal experience, that there are
other techniques for handling $@ than checking if ($@) that seem to work
better."
In my own experience, I find if ($@) to not always be the best approach.
For example, I'll often do:
my $variable_expected_to_be_truthful = eval {...}
or die "....\n";
I may or may not make use of $@. I find the above to be cleaner to read
than the attempt at mapping eval{}/if($@){} to try/catch, and I find it
to be more exact. After all, what happens if:
my $variable;
eval {
$variable = ...;
};
if ($@) {
die "...\n";
}
$variable->...;
What if $variable is undef by the time it reaches the bottom? I believe
I agree with Abigail, that if you really want to know whether $variable
contains a usable value, checking $@ is a backwards way to do it, and in
cases such as described in this thread, it's a broken way to do it.
> The possibility of DESTROY functions clobbering $@ is a design bug.
> I suggest that $@ should be automatically preserved across (localised
> to) DESTROY functions, and in the absence of such a change to the core
> I have argued for all DESTROY functions to explicitly localise $@ and
> the other global status variables
What might this break?
To me, it's a major change in behaviour. Perhaps a good one - but it
would have been better suggested before Perl-5.000 was released.
Cheers,
mark
--
Mark Mielke <mark@mielke.cc>
Thread Previous
|
Thread Next