in reply to Re^2: instantiating an smtp object
in thread instantiating an smtp object

clobbered

Carp Carp takes care not to clobber the status variables $! and $^E in the course of assembling its error messages. This means that a $SIG{__DIE__} or $SIG{__WARN__} handler can capture the error information held in those variables, if it is required to augment the error message, and if the code calling Carp left useful values there. Of course, Carp can't guarantee the latter.

$@

Interpolate. $@ is set if the string to be eval-ed did not compile (this may happen if open or close were imported with bad prototypes), or if Perl code executed during evaluation die()d. In these cases the value of $@ is the compile error, or the argument to die (which will interpolate $! and $? ). (See also Fatal, though.)

Replies are listed 'Best First'.
Re^4: instantiating an smtp object
by haukex (Archbishop) on Jun 06, 2016 at 11:50 UTC

    Hi $h4X4_|=73}{,

    It's unfortunate that the eval ...; if ($@) ... idiom is still very prevalent, there are many examples in the literature and even the eval docs use it! However, the issues I linked to previously have been around for a long time and even though Perl 5.14 fixed some of the major issues, as far as I have read the fixes are not perfect yet. The idiom eval { ...; 1 } or ... at least allows for reliable detection of when eval failed, even when $@ gets clobbered.

    As for $! vs. $@, I had a look at the source of Net::SMTP's new and it seems that $@ is explicitly set there.

    Regards,
    -- Hauke D

[reply]
[d/l]
[select]

      Please read perl doc my code is imuned to the bug state in the post Bug in eval in pre-5.14. I have posted an example but its not a good one. If you want to hide errors then use eval { 1 } if ! $self->{finished}; in DESTROY like that post has to cause the issue. But you cant say that is what is going to happen with /that/my/ code because I tested it for over 7 years in perl v5.8 and it works.

[reply]
[d/l]
[select]

        Hi $h4X4_|=73}{,

        I'll admit that I've never personally encountered the eval/$@ bug in the wild (yet), and the code in question does say use 5.014;. But, although admittedly unlikely, it's not impossible that Net::SMTP might someday update its DESTROY method with some code that still exhibits a form of the bug, or that the use 5.014; statement is removed later and the code is run on a lower version of Perl, or that the code is copy-and-pasted and used somewhere else where the bug suddenly shows up, and so on. So I still think that eval { ...; 1 } or ... is "better" (more reliable at detecting eval failures) than eval { ... }; if ($@) ..., and that it's a good habit to get into.

        Regards,
        -- Hauke D

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom