Daemon Continue after $SIG{__DIE_

rajuskark has asked for the wisdom of the Perl Monks concerning the following question:

$SIG{__DIE__}  = \&HandleDieError;


while (){
handleDBProcess();
RemainingTask();
FinalTask();
}

handleDBProcess {

#do something
#process

}


RemainingTask{
#again do something
#but got error
}

FinalTask{
#Final task to process
}



HandleDieError {
my $error = @_;

if ($error){
#Fixed error
#I want to continue
}
##but doen't do anything 
#it shows running but no any process goes on
}
[download]

Comment on Daemon Continue after $SIG{__DIE__} Download Code

Replies are listed 'Best First'.
Re: Daemon Continue after $SIG{__DIE__} by Corion (Patriarch) on Oct 19, 2015 at 11:50 UTC
What should the program do if the `insert` part fails or the `update` part fails? Most likely, you want to think hard and long about how to prevent the `insert` part from being run multiple times. The even harder part is how to prevent the `update` part from being run multiple times or having cumulative effects. Also, see DBI on how to catch and retry failing statements.	[reply] [d/l] [select]
Re: Daemon Continue after $SIG{__DIE__} (eval) by tye (Sage) on Oct 19, 2015 at 14:24 UTC
__DIE__ is not for making exceptions non-fatal. Only eval is. - tye	[reply]
Re: Daemon Continue after $SIG{__DIE__} by soonix (Chancellor) on Oct 20, 2015 at 11:12 UTC
Several people already tried this, for an interesting guide through such an endeavour see →Perl's Warn and Die Signals. The "official" statement is in perlvar. If you look there for `__DIE__`, there's the statement When a __DIE__ hook routine returns, the exception processing continues as it would have in the absence of the hook, unless the hook routine itself exits via […something that would lead to the end of the program, anyway] The above mentioned documents put (and answer) the question "how", more important is the question "why", which you must answer yourself.	[reply] [d/l]
Re: Daemon Continue after $SIG{__DIE__} by soonix (Chancellor) on Oct 21, 2015 at 05:52 UTC
The answers you have gotten so far seem not to help you. This is because the information you gave with your question does not help finding the right way. If you could show ~~that~~ how you did "think through" the problem (I don't know if this is the right expression), e.g. by answering these questions, … or by telling us how your problem arises in the first place (what makes the signal appear?) - this would greatly help finding a useful solution for you.	[reply]