Along the lines of using a global, I cram my own flag right into the cgi object.

Yeah, probably not the best idea, as my variable just might clobber some internal CGI variable, but, hey, it works...

So whenever I start a new page, anywhere within my system of cooperating CGI apps, I note the header was sent:

print 
    $q->header(),
    $q->start_html(-title=>"R3: edit ads",
           -style=>{-code=>&css()});
$q->{header_was_sent}++;
[download]

And then in my error code (same code shared by all the scripts in the system), I can see if I need a header or not.

Since this on an intranet, and everyone using the apps is trusted and more-or-less SQL and database savvy, I send lots of info back to the user in the error call. (This would be a really bad idea for a public internet app!!!) Here's my error code:

sub error {
    my (@msgs) = @_;
    my $firstline = shift(@msgs);
    if (!$q->{header_was_sent}) {
    print
        $q->header(), 
        $q->start_html(-title=>"R3: error", -style=>{-code=>&css()});
    }
    print

    "<br><marquee><font class=\"error\"> Need help?  Something busted?
+ Confused?  Email the error message below to XXXXXXXXXXXXXXX </font><
+/marquee><br>",
    "<h1 class=\"error\"> Error: $firstline </h1><h2 class=\"error\">"
+,
    scalar(localtime), "<br>",
    join ("<br>",@msgs), "</h2>\n";
    print $q->end_html;
    exit(0);
}
[download]

The marquee tag is annoying, but it gets noticed.

When I trap DBI errors, I send the error routine lots of information to help the user figure out what went wrong, including the sql itself and the DBI error string...

  my @inqs = @{$dbh_g->selectcol_arrayref($sql,undef,$adid)} or &error
+("Bad selectcol in get_inqs", $sql, $dbh_g->errstr);
[download]

Again, this level of openness is not suitable for open web!