Module wants to die! How do I handle this?

[jdtoronto]

Esteemed monks,

Please allow me once more to don the cowl of newbieness and ask:

I am using Net::DNS::DynDNS in my application. Whenever it encounters an error it 'dies'. However many of the errors which cause death can be handled intelligently! But how do I stop it from die'ing? Or do I just rewrite it completely?

jdtoronto

[JediWizard]

I would wrap the offending calls in an eval, and then check the value of $@ after to look for errors. See (brief) example below:

eval{&i_will_die};
if(defined($@)){
  # handle the error
}

sub i_will_die
{
   die "Life stinks, I give up\n";
}

[haoess]

$@ seems always to be defined:

$ perl -Mstrict -wle 'print defined $@'
1

Therefore you better check for a true value in $@:

if ($@) { ... }

--Frank

[perrin]

Hi JD. The module is trying to throw an exception. This is generally better than using return codes. To handle exceptions in perl, use the block form of eval. Check out the perlfun man page (or Programming Perl) for the details.

[ysth]

This is generally better than using return codes.

Depends on what kind of programming you are doing, and what you feel comfortable with. I've found return codes to be better to my taste in most cases.

[perrin]

You're certainly entitled to do it your own way, but modern programming practice is moving away from return codes to indicate errors and toward exceptions. You can see this in most recent books and in the prominent place exceptions have in recently designed languages.

[radiantmatrix]

There are two ways to deal with this. One is mentioned above, and that is wrapping dying code in eval{}, which is sort of like Java's try setup. Code inside the eval block may die, but if it does, it merely ends the eval block (and, as a bonus, $@ gets set to the message it died with).

eval {
   ... code that might die ...
};
if ($@) {
   # if we had an error.
   ... read $@ and decide on what to do ...
}

However, if you will always do the same thing upon death, you can also override the "die" signal. This would be used, for example, if you want to return a useful exit code to a wrapper script.

$SIG{__DIE__} = \&my_death;

sub my_death {
   warn @_;          #propagate the message via warn()
   POSIX::_exit(42); #exit with code 42
}

You should read about this in the perldocs before going the route above, as certain things (like I/O) are not a good idea when your app is in the throes of death. ;-)

Update: I forgot to add, if you do want to do "dangerous" things to recover from a fatal error, one way to accomplish this is to wrap your script's main logic in a subroutine (say, main()), and do something like this:

sub main {
   ... main program logic ...
}

eval { main() };
if ($@) {
   ... handle any fatal errors ...
}

This allows you to, among other things, put common housekeeping-on-exit routines inside an END{} block. For example:

eval { main() };
if ($@) {
   warn "FATAL: $@"; ## all I want to do is warn about the fatal.
}

END {
   close_all_files();
   issue_done_to_server();
}

This way, you will close all files and issue a done to the server (I made those up, BTW) whether you had fatal errors or not.

[runrig]

Other excellent answers are around here, but I'm still wondering about the context of your statement that the errors can be "handled intelligently." Do you mean, e.g., that in some place where the module dies, some alternate value could be used so that the module wouldn't have to die and could continue on it's way giving you useful results, or do you just want to trap errors so that your main program can continue (but with no more results from the module)? All of the answers here (eval) address the latter case, but I think the former case would require rewriting...we'd have to see specific cases where you think it shouldn't die.