As you see, I have defined a custom "die" handler. For some reason,
when I run this script, I get three "die" messages from this handler,
even though the script successfully does the "put" and cleanly exits
with the polite message.

Why is Net::SFTP triggering my die handler when nothing seems to be
dying?

Firstly, I knew nothing about this module, so my suggestions may be not
useful for you.

After I checked perldoc about this module, I guess you can take a look
at the following issues:

1) in the Net::SFTP->new(%host, %arg), there is a "warn" option in the
hash %arg, it shows:
warn: If given a sub ref, the sub is called with $self and any warning
message; if set to false, warnings are supressed; OTHERWISE they are
output with 'warn' (default).
so, you may get a default warning from this line if your failed in
creating a new instance.
> Why is Net::SFTP triggering my die handler when nothing seems to be
> dying?
2) $sftp->status
If a low-level protocol error or unexpected local error occurs, we DIE
with an error message.
so you may trigger your die handler here(just guess)

3) another error info may come directly from the "warn" clause..

IMHO, this module has embedded with independent error handling
mechanism so you dont have to do them all by yourself.

I am on WinXP SP2 with perl 5.8.7 (815).
> As you see, I have defined a custom "die" handler. For some reason,
> when I run this script, I get three "die" messages from this handler,
> even though the script successfully does the "put" and cleanly exits
> with the polite message.

Hmmm ... I had thought I all that was installed when I installed
Net::SFTP via ppm.

I installed Math::BigInt::GMP and Math::BigInt::Fast via ppm,
Math::BigInt:ari using Makefile.PL, and run into problems compiling
Math::BigInt::FastCalc (in case anyone knows what the to do, the
problem is "unresolved external symbol __ftol2"). Anyway, installing
what I was able to install reduced the number of "I'm dead" messages:

I think it would be nice, at least for debugging purposes, if you had your
sub print out the error message it was called with. Then you would know
what it was.

....
>
> As you see, I have defined a custom "die" handler. For some reason,
> when I run this script, I get three "die" messages from this handler,
> even though the script successfully does the "put" and cleanly exits
> with the polite message.
>
> Why is Net::SFTP triggering my die handler when nothing seems to be
> dying?

You should ask Perl that, not us!

However, from perldoc perlvar:

Due to an implementation glitch, the $SIG{__DIE__} hook is
called even inside an eval(). Do not use this to rewrite a
pending exception in $@, or as a bizarre substitute for
over- riding CORE::GLOBAL::die(). This strange action at a
distance may be fixed in a future release so that
$SIG{__DIE__} is only called if your program is about to
exit, as was the original intent. Any other use is
deprecated.

So it would be my guess that Net::SFTP is dying from inside an eval, as
part of its normal course of business, and you are intercepting those dies.

But this lead me to ask a broader question. What are you trying to do, and
why are you using a SIG die handler, rather than eval{}, to do whatever it
is you are tyring to do?

wrote in news:20060131110941.189$:
> wrote:
>> Greetings. Kindly consider, if you please, this trivial sample script
>> which illustrates my question:
>>
>> #!/usr/bin/perl
>> use warnings; use strict;
>> use Net::SFTP;
>>
>> local $SIG{__DIE__} = sub {
>> print "Oh no - I'm dead!\n";
>> };
>
> I think it would be nice, at least for debugging purposes, if you had
> your sub print out the error message it was called with. Then you
> would know what it was.

Yeah ... I did it the long hard way ... It was dying in a bunch of
evals.
> However, from perldoc perlvar:
>
> Due to an implementation glitch, the $SIG{__DIE__} hook
> is called even inside an eval(). Do not use this to
> rewrite a pending exception in $@, or as a bizarre
> substitute for over- riding CORE::GLOBAL::die(). This
> strange action at a distance may be fixed in a future
> release so that $SIG{__DIE__} is only called if your
> program is about to exit, as was the original intent.
> Any other use is deprecated.

Oooops ... I missed that and I wasted a lot of time.
> So it would be my guess that Net::SFTP is dying from inside an eval,

Guest

wrote:
> I think it would be nice, at least for debugging purposes, if you had your
> sub print out the error message it was called with. Then you would know
> what it was.

Do you mean $! ? I wasn't sure $! would be reliable here. I actually
included $! as I was trying to figure out what was going on, and I got
a bunch of (seemingly) meaningless messages.
> However, from perldoc perlvar:
> <snip perldoc>
> So it would be my guess that Net::SFTP is dying from inside an eval, as
> part of its normal course of business, and you are intercepting those dies.

I'm glad you were able to translate that perldoc statement (which I
struggle to understand, with little success) into something that makes
sense! Thanks!
>
> But this lead me to ask a broader question. What are you trying to do, and
> why are you using a SIG die handler, rather than eval{}, to do whatever it
> is you are tyring to do?
>
The die handler is designed to catch my own die() calls. I die within
my script under various dire circumstances, but I want to do some
housecleaning before I really leave (dispatching final logging methods,
closing databases cleanly, etc), so I use the handler. Maybe that's not
the best way to do it...

I didn't anticipate catching any die()s from Net::SFTP because the docs
for the module claim it die()s only in under fairly restrictive (and
unlikely) conditions. Your speculation about the module die()'ng inside
evals sounds plausable, and will make me re-think my exit strategy for
exception handling.

Thanks, Xho (and thanks, Sinan, for your amazing efforts to help also,
which were apparently thwarted by what seems to be a bug in Net::SSH on
Windows - but I'm a UN*X weenie).

Guest

wrote:
> wrote:
>
> > I think it would be nice, at least for debugging purposes, if you had
> > your sub print out the error message it was called with. Then you
> > would know what it was.
>
> Do you mean $! ? I wasn't sure $! would be reliable here. I actually
> included $! as I was trying to figure out what was going on, and I got
> a bunch of (seemingly) meaningless messages.

Mind you, I've never actually used SIG die handlers, so this is based on
the doc, not from experience, But I think what you should print would be
$_[0].

The routine indicated by $SIG{__DIE__} is called when a
fatal exception is about to be thrown. The error message is
passed as the first argument.

(OK, so now I guess I have actually used SIG die handlers, so disclaim my
disclaimer.)
>
> > However, from perldoc perlvar:
> > <snip perldoc>
> > So it would be my guess that Net::SFTP is dying from inside an eval, as
> > part of its normal course of business, and you are intercepting those
> > dies.
>
> I'm glad you were able to translate that perldoc statement (which I
> struggle to understand, with little success) into something that makes
> sense! Thanks!

You're welcome.
> >
> > But this lead me to ask a broader question. What are you trying to do,
> > and why are you using a SIG die handler, rather than eval{}, to do
> > whatever it is you are tyring to do?
> >
> The die handler is designed to catch my own die() calls. I die within
> my script under various dire circumstances, but I want to do some
> housecleaning before I really leave (dispatching final logging methods,
> closing databases cleanly, etc),

I think dispatching final logging methods should probably happen in an END
block, or perhaps should be automatically triggered when the logging object
goes out of scope and is destroyed (which happens even if you are exiting
via die).

For closing databases cleanly, it is not clear to me that one can generally
do a better job at handling that than the code already built into DBI does,
which is triggered when an open db handle goes out of scope or is
destroyed, for example during clean up after a uncaught "die". There are
exceptions to every generalization and YMMV, of course.

Except the latter doesn't intercept other peoples dies if those dies are in
evals of their own, while the former does. (One potential problem is that
the handler can be a closure upon lexicals in the block, while the if after
the eval can not.)

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!