in reply to Re: Understanding compiletime vs. runtime in thread Understanding compiletime vs. runtime
full disclosure: The stuff in the BEGIN block is something I copied from another code (someone else's suggestion). It seemed to do what I wanted, so I haven't spent a lot of effort really understanding it.
Now, putting some effort to understand it, I believe what I am ending up doing is redirecting all the errors to foo.err, and all non-errors to foo.log. Which is ok. As quite a pleasant sideeffect of my ignorance, that _is_ what I want.
However -- I don't want to program to die as it seems to be doing. And, from your suggestion, it seems I will further insure that all warnings become dies. If, from what you say above, Mail::IMAPClient is just warning, why is the program die-ing?
Btw, per thor's suggestion, perl -c script.pl sends script.pl syntax OK to foo.err.
In the end -- I want there to be no die-ing at all, absolutely, unless a SIGINT is sent. In all cases other than a SIGINT, I want the error message written to foo.err and for the script to recover and merrily continue its way.
Since the above is a fair bit beyond my current understanding, I need some guidance on how to implement it.
Many thanks for your advice.
Re^3: Understanding compiletime vs. runtime
by tilly (Archbishop) on Feb 05, 2005 at 08:42 UTC
|
Let me explain my suggestion in more detail.
You're having errors in the eval, and you want to trap them. The eval will trap any die and store it in $@, which you're then processing. The problem is that a warn does not get trapped by eval, it just goes to STDERR. So the error is printed to that file, and then when you test $@ you have no sign that there was a problem.
My suggestion turns warns into dies so that eval can trap them so that the code that you presented does something closer to what you say that you want. You're right that I've left warns as dies afterwards. That's fixable. In fact try the following variation of the eval and tell me whether it works better:
# create an IMAP connection
eval {
# This is the inserted line.
local $SIG{__WARN__} = sub {die @_};
$imap = Mail::IMAPClient->new(
Server => $IMAP,
User => $UNAME,
Password => $PWD,
Uid => 0,
Debug => $DEBUGGING,
) or carp "Cannot connect to $IMAP as $UNAME: $@";
};
I give you good odds that this will cause your eval to do what you want it to do, and it won't make warns into dies later in your program. | [reply] [d/l] |
|
In fact try the following variation of the eval and tell me whether it works better
You the monk!
Yes, it does. And, because of your patient explanation, I understand better what is going on. A few questions niggle my mind and remain --
- When I convert the warn into a die it gets trapped by eval. Why? I mean, why doesn't die behave the same way as warn... it is, after all, an error, and should be redirected to STDERR. Mind you, the way it is working _is_ how I want it to be. I just don't get this discrimination.
- When warn gets piped to STDERR, why does the script stop working? After all, it is just a warn and not a die. I would expect the script to warn and then continue working merrily. I've put it in an infinite loop with a sleep statement in there, so it should just take a breather and then try again. Except, if I don't modify eval as you have suggested above, the warn goes to STDERR and the script quits.
- Since the above modification works, it should also work if instead of warn I explicitly use die. In fact, I am going to try that right away and see if it does so. In that case the local modification of SIG{__WARN__} should not be necessary.
- And finally, I am assuming I can convert other SIGs the same way. In fact, I don't want the script to die ever unless CTRL-C/BREAK is pressed (SIGINT) or the computer is shutdown. Any caveats to that?
In any case, muchas gracias por su ayuda.
| [reply] |
|
| [reply] [d/l] [select] |
|
|