In a CGI if you do:

die "Bugger!\n";
[download]

then the user will not get an error message. Typically they will get a 500 internal server error or a blank screen, depending on if a header has been output. They will not see the error message. A die nice routine might be:

# sack the QA team! 
sub die_nice {
    my ( $real_error ) = @_;
    email( $ADMIN, $real error );
    warn $real_error;                 # this will log it like die
    # Make sure we have a valid header....
    print "Content-Type: text/html\n\n";
    # Lie to the user, we don't want to let them know our code is unst
+able now do we?
    print "
<p>Sorry the server is unable to respond to your request due to routin
+e maintenance
<p>Please try again later....";   # yeah right.....
  exit 1;
}
[download]

So rather than die-ing you die nice ie do some stuff you want. You could just set a DIE handler but.....

As tachyon says, the "dienice" function is a function which makes your errors look prettier than the standard "internal error" page. They have become popular largely thru their use in a number of beginners' CGI books.

However, there's one important point to note with a "dienice" routine. tachyon's version does the right thing by simply displaying a vague error message to the user, but many versions from books display the complete error message to the user. This is generally a bad idea. Giving actual Perl error messages to users should be avoided. It will probably confuse your users and it gives too much information to the black-hats.

The generic "internal server error" page is the way it is for a very good reason. It gives the user all the information that is necessary. The important thing is to write the real error message into the web server error log where it belongs so the webmaster can see it.

For this reason, I very rarely use a "dienice" function, prefering to write a custom 500 error page which mirrors the look and feel of the web site.

Just to add to the custom 500 page theme.....

# in httpd.conf you need some lines like:

ErrorDocument 404 /custom_error/error_404_not_found.htm
[snip]
ErrorDocument 500 /custom_error/error_500_internal_server_error.htm

# then you need a custom doc where you specified it above, the guts of
+ our 500 is .....

<div id="contentstart">
<h3>500 Internal Server Error</h3>
<p><img border="0" src="/images/thumbs_down.gif" width="14" height="17
+"> 
Sorry a 500 Internal Server Error error has occurred.</p>
<p>The server encountered an unexpected condition which prevented it f
+rom fulfilling 
the request. This is probably due to routine maintenance. Then again w
+e may have to 
sack the programming team! This error has been logged and we will look
+ into it, 
if it persists.</p>
<p>Sorry you have experienced a problem.</p>
<p>Click <a href="/index.htm">here</a> to return to our entry page, or
+ 
<a href="/index/contact.htm">here</a> to contact us about the issue.</
+p>
<p><i>Kind Regards</i></p>
<p><i>The BlahBlah team</i>
</p><hr width="100%"><i>Apache 1.3.29 Server at blah.org Port 80</i>
</div>
[download]

cheers

tachyon

Sort of a pedant's note. Click 'here' links are pretty awful. Aside from all the usual gripes (bad indexing by search engines, &.c), which are largely useless in the case of an error page, it reduces the usability for visitors with disabilities.

It's very hard for, say, a visually-impaired person to have their assistance software try to distinguish between 'here' and 'here'. A better section would be:

<!-- snippet -->
<p>Sorry you have experienced a problem.</p>
<p>You may wish to visit <a href="/index.htm">our entry page</a>; or,
<a href="/index/contact.htm">contact us</a> about the issue.</p>
<p><i>Kind Regards</i></p>
<!-- end snippet -->
[download]

This is one of those moments where I wish I had one of those amnesia flash things from Men In Black. A quick survey via google has led me to believe that every example of code that uses the literal dienice subroutine out there is unadulterated crap, having been cut and pasted from some ancestral piece of mid 90's perl 4 code and hacked without any great understanding until it does what the person wanted. You probably do not want to be using this code as an example of good Perl programming. Of course I am probably being entirely unfair to some very good examples of code but there you go.

In addition to the comments of tachyon and davorg, you might also want to look at the facilities offered by the module CGI::Carp which, through its fatalsToBrowser mode and the set_message subroutine allows you to catch to catch a die and then present your own message to the users browser, of course it is unwise to be showing the real error message to the whole world but it often makes debugging easier, so you can for instance check if the request is coming from your IP and if so show the whole error otherwise showing a bland message:

#!/usr/bin/perl
                                                                      
+          
use strict;
                                                                      
+          
use CGI::Carp qw(fatalsToBrowser set_message);
                                                                      
+          
                                                                      
+          
my $sub_message = sub {
                        my ($message) = @_;
                        if ($ENV{REMOTE_ADDR} eq '127.0.0.1')
                        {
                           print "Oops: $message";
                        }
                        else
                        {
                           print "Unable to process, please try later"
+;
                        }
                     };
                                                                      
+          
set_message($sub_message);
                                                                      
+          
die "aiee!";
[download]

/J\

Does fatalsToBrowser give too much information to a cracker?