in reply to Re: $@ gets set differently on eval and Log::Dispatch::Email
in thread $@ gets set differently on eval and Log::Dispatch::Email

see Devel::EvalError it will probably help some (Why $@ is unreliable)

Thanks, that's the right direction, using Devel::EvalError instead of eval directly works. Does this package provide any hints on where eval and DESTROY are used without localizing $@? That's how I interpreted some of the statements but I can't figure out how to enable mentioned debug output. I came across that problem before in some of may packages and added a localization of $@ in DESTROY by convention. I think I would prefer this workaround for now until I maybe decide to switch to Devel::EvalError everywhere. I couldn't find any combination of DESTROY and eval in Log::Dispatch but there must be one somewhere as without Log::Dispatch everything was working fine...

  • Comment on Re^2: $@ gets set differently on eval and Log::Dispatch::Email

Replies are listed 'Best First'.
Re^3: $@ gets set differently on eval and Log::Dispatch::Email
by Pickwick (Beadle) on Aug 12, 2013 at 17:24 UTC
    I couldn't find any combination of DESTROY and eval in Log::Dispatch but there must be one somewhere as without Log::Dispatch everything was working fine...

    For some reason the cause of the problem was not in Log:.Dispatch, but in one of my classes and their destructors. I didn't use eval directly, but indirectly it was used somewhere within Log4perl, which was used to log some debug statements in the destructor. After I added local $@; before the logging statements error trapping worked again. Don't know why the problem was only triggered using Log::Dispatch, though.

    Looks like I have to really switch to Devel::EvalError in the future, problems like this are very hard to find.

      It would be easier to find, if you always use
      eval { main(); 1; } or do { # error handling with $@ }
      that way you will at least find that error happened.

        Looks pretty nice and creates short lines, thanks!