Consider carefully the wisdom of doing so. Many of us don't use CGI::Carp on sites which will be exposed to the public because detailed information about how and why the code failed could be very helpful to an attacker who wished to compromise the site by deliberately causing it to fail and, perhaps, even help him engineer the means to cause it to fail in a specific manner for his advantage.

CGI::Carp is a handy development tool (especially when you don't have direct access to the server logs), but you'd probably be better off using a more verbose construct which lets you tell the user information which is both safe for you and useful for him¹. Maybe even recover from the error and go on instead of dying. Something like:

unless (my $address = retrieve("/tmp/$session_file")) {
  warn "no session file $!\n";
  create_new_session_file("/tmp/$session_file");
  redirect_user_to('new_session_page');
}
[download]

CGI::Carp provides a handy hook for this:

use CGI::Carp qw( fatalsToBrowser set_message );

BEGIN {
    sub handle_errors {
        my $message = shift;
        # Insert some custom code here, for example check the remote address ...
        print "<h1>Oh gosh</h1>";
        print "<p>Got an error: $message</p>";
    }
    set_message( \&handle_errors );
}

dsheroh: Thanks for that, was actually contemplating that concept myself once I saw fatals going to my browser. Like you said, it is darn handy during development. And your suggestion is actually what I was originally looking for--thanks!

WizardofUz: that's quite handy as well--y'all have given me a lot of tools to work with, and I am grateful!

eval {
    your code with die here ...
};

if ($@) {
  # print to web browser
  print CGI::header ...;
  print "Error occured: $@";
  die;
}
[download]

Rock, CGI::Carp for the win, thanks y'all. Thanks for the input too, Happy Barney--that is a good concept to keep in the old tool chest :-)