What have you tried?

Do you have:

use CGI::Carp qw(fatalsToBrowser); # Remove for production code
[download]

I use an error reporting sub for reporting "standard" errors and dumping the CGI parameter list:

sub showError {
    my $err = shift;

    print header();
    print start_html("IsosimCGI_Error");
    print h1("IsosimCGI Error");
    print p ($err);
    
    my %params = Vars ();
    for my $param (keys %params) {
        print br ("$param -> $params{$param}");
    }
    
    print end_html();
    exit 1;
}
[download]

Have you tried wrapping your troublesome code in an eval:

eval {
    #troublesome stuff here
};

ShowError ($@) if $@;
[download]

In cgi, a message to STDERR will generally show up in the httpd's error log. For non-fatal errors, Perl's warn will do the job. For fatal ones, die.

You can keep error messages in a variable by opening STDERR to a reference to that variable. Something like:

{
    my $errors;
    open local(*STDERR), '>>', \$errors or die $!;
    # do stuff, can call external functions that warn or die
    if ($errors) {
        print error_template($errors); # however you do that
        exit 0; # or non-zero if we want to tell the server we failed
    }
    # maybe do more stuff - success branch
}
[download]

How are you using Template Toolkit? Maybe you are ignoring errors that you are getting. You haven't posted any code, so I cannot see whether this is the case.

In the manual are examples that check the return value from process and die with the error method when unsuccessful. This will result in diagnostics on stderr. Is your code doing this?

I looked at the piece of code that you mentioned and maybe part of the problem is that I am using cpan:://CGI::Application::Plugin::TT The plugin does not mention much in reference to Template errors except that I can have an 'Error' runmode to display the an error template.

I was hoping there was a variable that could be set when initializing the Template configuration that would force the template to die with the error message or stick the error in a value that is accessible by the template.

Update: I am also wondering if might have to do with the way CGI::Application handles carp calls on a Win32 box. I looked at the source code for the plugin and it calls croak which, I don't think should be a problem, but I am not sure how it is being handled.

Update 2: Evidently CGI::Application does its own eval on executed code and sticks in the $@ variable and will call the error runmode. I cannot wait to get home to see if this works.

sub error {
    my $self = shift;
    my $error = shift;
    
    # Do something with the error - e.g. write it to a log file
    $self->logger->error("Warning error: $error");
    
    #.... and then provide friendly message to user
}
[download]