So let me state facts about how Perl works.

• STDERR is a filehandle, just like STDOUT, just like ones you open on files. Nothing more, nothing less. It is somewhat special in that it happens to be a filehandle on which error messages are likely to be written, but nothing special happens when you write to it.
• When you warn, Perl does something like this:

  sub warn {
    my @messages = @_;
    unless (@messages) {
      @messages = "Warning: something's wrong";
    }
    if ($messages[-1] !~ /\n$/) {
      my ($package, $file, $line) = caller();
      $messages[-1] .= " at $file line $line\n";
    }
    if ($SIG{__WARN__}) {
      $SIG{__WARN__}->(@messages);
    }
    else {
      print STDERR @messages;
    }
  }
  [download]

• When you die, Perl does something like this:

  sub die {
    my @messages = @_;
    unless (@messages) {
      @messages = "Warning: something's wrong";
    }
    if ($messages[-1] !~ /\n$/) {
      my ($package, $file, $line) = caller();
      $messages[-1] .= " at $file line $line\n";
    }
  
    if ($SIG{__DIE__}) {
      $SIG{__DIE__}->(@messages);
    }
  
    foreach level (travel up the callstack) {
      if (this level is trapping exceptions) {
        $@ = join "", @messages;
        transfer control to where that's caught.
      }
    }
  
    unless ($SIG{__DIE__}) {
      print STDERR @messages;
      exit(255);
    }
  }
  [download]

• eval catches exceptions.

1. Why is die trapped by eval but not warn? Well in the pseudo-code above, you can see that die triggers an exception, and eval traps that exception. warn does not trigger an exception. Therefore only die is caught.

   Going to a higher level of explanation, it is because Larry Wall thought that it would be more useful to trap die than warn. And it is useful because the primary thing that die does is change the flow of the program, and someone might want to regain control somewhere. By contrast the primary thing that warn does is print to STDERR, and people can already control STDERR.

2. Why does my script stop working? I don't know. I know that the code that you've presented shouldn't have it stop working. It may be that goto_sleep doesn't do what the name suggests. It may be that some step inside of process fails if you don't have $imap. Perhaps you want to return if $@ is set because the rest of process() will fail?

3. My code should work if instead of converting warn into die, I just use die in the first place. Yes. I only suggested the other since I didn't know how much control you have over Mail::IMAPClient.

4. Any caveats to converting other SIGs the same way? Well, you have to track them down. And most of them won't stop your program anyways, so I wouldn't worry about it. You'll probably get farther if you avoid exit and use eval liberally.

   However I'll give you a random warning. A common problem with Unix systems is that people write daemons like this and expect them to always be up. Then months later the system reboots, and people have forgotten about the necessary daemons. Then things break and it is really hard to track down why.

   The solution is that if you write something that you really want to always be running, just have it try to launch regularly from cron, check if it needs to run (checking for a a control file is a common way to do this), and if it does, then run it. Otherwise have it quietly exit.