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

Hi $h4X4_|=73}{,

Regarding the idiom eval ...; if ($@) ..., see for example Bug in eval in pre-5.14 or the "Background" section in Try::Tiny. The better idiom is eval "...; 1" or handle_error($@). And in this case I'd suggest eval BLOCK instead of eval STRING so that syntax errors can be caught at compile time.

Also, in "say "Unable to connect to '$host'. $!"", I think that should be $@ instead of $! (at least per the documentation of Net::SMTP).

Regards,
-- Hauke D

Update: s/patter?n/idiom/

Replies are listed 'Best First'.
Re^3: instantiating an smtp object
by $h4X4_|=73}{ (Monk) on Jun 06, 2016 at 11:21 UTC

    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.)

      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

        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.