Front page | perl.perl5.porters |
Postings from March 2008
On Fri, 21 Mar 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. > > The possibility of DESTROY functions clobbering $@ is a design bug. I agree with that. > 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. I would find this an acceptable change for 5.12 (with a corresponding warning in 5.10.1 docs). If we can't agree on doing that, then a somewhat reasonable compromise might be to only localize $@ during the processing of a die() call itself. That way any additional exceptions thrown by destructors won't overwrite the original exception. I wonder if for consistency eval() should then check $@ *after* the stack-unwinding and change the return value to undef if $@ is true? Or why should the eval() be considered successful if the failure of a destructor is deemed important enough to change $@? I would still prefer to always localize $@ around DESTROY calls. Cheers, -Jan PS: This is another can of worms, but I would even argue that any exception thrown that would unwind outside the DESTROY call frame while we are already unwinding the stack for an earlier exception should be a fatal error. This would essentially mean that DESTROY should not throw exceptions at all (unless we make the fact that we are unwinding the stack already available in something like $^S).Thread Previous | Thread Next