Bug #54050 for Try-Tiny: localize and unset $SIG{__DIE__}

2010/1/28 Michael G Schwern via RT <bug-Try-Tiny@rt.cpan.org>: Show quoted text
That's making a fairly big assumption about the usage of $SIG{__DIE__}, sometimes people rely on it for things that *should* be triggered in an eval. For example by using it to automatically convert errors to exception objects is something i've seen in real code before, and that's pretty much only useful *inside* an eval. If existing code can't be converted to using Try::Tiny without a full audit of the code being used inside the eval that's a pretty big caveat, so I'm uncomfortable making this change. One option would be to make this a per consumer import-time decision (use Try::Tiny :disable_sig_die => 1) or something like that, but that would seriously complicate the code, which I think still serves as a useful way of documenting the problems with eval in the comments etc. I was very hesitant to add @DB::args and 'finally' because of that, but eventually caved on 'finally'.

try might be different from eval in the local semantics, but all of the differences are apparent in the lexical scope of usage. Secondly, $SIG{__DIE__} can be used legitimately inside an eval, and has been many times before, I'm not going to break that because it will make using Try::Tiny a lot more difficult for me and many others. There are other try/catch modules on the CPAN that meddle in this sort of idealism, and I think that's just not workable. Code that used to run in global contexts may be later reused inside an eval, thus causing behavior changes that are not directly evident. You're also assuming that running -MDevel::NoGLobalSig=die would do full path coverage, which is most definitely not guaranteed, and precisely the combinatorial issue when bits of code that are not lexically adjacent interact with one another. I don't want another UNIVERSAL::isa on my hands, especially since Try::Tiny was not a tounge in cheek acme module to begin with.

(I am, as well, talking about the module UNIVERSAL::isa) I'm confused because your argument has very strange priorities. I'll assume I'm just misunderstanding and reiterate what I'm hearing back to you. 1) The important thing is to help users transition from eval to try. 2) Someone might have written an eval expecting $SIG{__DIE__} to apply. 3) Someone converting the eval (maybe the person who wrote it, but probably not) might not realize that there is a $SIG{__DIE__} in effect and it is necessary for the correct operation of this eval. 4) The existence of a $SIG{__DIE__} is not obvious just from looking at the eval block requiring a full audit of the code or a very good test suite. 5) Therefore, making try immune to $SIG{__DIE__} makes #1 harder. 6) Also by removing $SIG{__DIE__}'s action at a distance upon try this would somehow constitute action at a distance. Which is all logically consistent (except #6 which is fairly Orwellian)... but assumption #2 is so unlikely as to be an absurd basis upon which to make a decision. Even if it is true, it's actively dangerous. The code one programmer writes might be expecting a $SIG{__DIE__} to be in effect and work with it, but all the rest of the code in the process, including CPAN modules, will not. Then something loads CGI::Carp, silently blows away your $SIG{__DIE__} and whatever eval/try logic that depended on $SIG{__DIE__} fails. That is, the argument is saying that Try::Tiny should support a use case that's highly unlikely, extremely fragile, a documented design bug in Perl and should be removed when its encountered. Worse, it should support it to the determent of the extremely common trap of an eval/try *not* expecting there to be a $SIG{__DIE__}. For every bit of code out there that would break if it didn't honor $SIG{__DIE__} I am not exaggerating when I say there are 20, 100 or even 1000 evals that should not trigger a $SIG{__DIE__} but fail to guard against it. Do I have it right? I hope not. I'm going to complete the argument against it, but I hope I'm not sock puppetting you in doing so. While I agree that the $SIG{__DIE__} problem is non-lexical, it's existence is highly unlikely. Proposing it as a real barrier to adoption is absurd when compared to the existing changes in behavior of return, $! and $@ ($! and $@ also being non-lexical) which are much higher and far more frequent and realistic barriers. Worrying about $SIG{__DIE__} is like shaving an ounce off a backpack while keeping the cast iron skillet. It just doesn't make a difference. Furthermore, if your code as a $SIG{__DIE__} which is expecting to dip into eval, it is far more likely that programmers will not realize it exists and write evals without $SIG{__DIE__} protection generating bugs. Therefore, any system designed assuming $SIG{__DIE__} will be dipping into eval should either already have been redesigned or will continue to generate bugs. In which case any bugs caused by transitioning from eval to try are simply the latest in a long string of bugs caused by the design. $SIG{__DIE__} is dangerous in production. The only sane uses for $SIG{__DIE__} is as a global "catch" block or as a debugging and analysis tool. As to the former, everything in try is already caught (or deliberately ignored). As to the latter, this is not critical production functionality that Try::Tiny needs to prioritize. Finally, the UNIVERSAL::isa analogy. One module loading UNIVERSAL::isa affected code in every other module (I don't believe it does anymore... or at least it tries not to). This is like one module defining a $SIG{__DIE__} and inadvertently affecting every eval and try in every other module. That is action at a distance. I'm not sure how try ignoring $SIG{__DIE__} is analogous to UNIVERSAL::isa. On 2011.4.30 3:22 AM, Yuval Kogman via RT wrote: Show quoted text
-- 39. Not allowed to ask for the day off due to religious purposes, on the basis that the world is going to end, more than once. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/