in reply to Re: Rethrowing with die $@ considered harmful
in thread Rethrowing with die $@ considered harmful

This was a nightmare to track down. The solution was to simply localise $@ in the destructor.

Yeah, side effects and destructors don't mix well accoding to perlobj...

Since DESTROY methods can be called at unpredictable times, it is important that you localise any global variables that the method may update. In particular, localise $@ if you use "eval {}" and localise $? if you use "system" or backticks.

You can see where I got bit by this a few years ago here Devious Destructor. It would be nice if perl did this for you (but perhaps it can't?) since sometimes it's not obvious that what you are calling is altering globals, and it's not easy to remember to do this.

  • Comment on Re^2: Rethrowing with die $@ considered harmful

Replies are listed 'Best First'.
Re^3: Rethrowing with die $@ considered harmful (best practices)
by tye (Sage) on Jul 21, 2006 at 15:27 UTC

    So I think the better solution is to extend this warning / practice to FETCH- and STORE-type subs, rather than having code that uses $@ have to be paranoid that $@ might be tied to something that uses eval in its FETCH. Such a FETCH should be considered "broken" from a "best practices" point of view.

    Being paranoid about $@ changing on you is not a bad practice. I'm just saying that in comparison, using eval w/o local($@) in a FETCH is a worse practice. And that is especially true for a FETCH meant to be used with $@.

    - tye