tcf22 has asked for the wisdom of the Perl Monks concerning the following question:

Hello
I was wondering if anyone knew of a way to trap a cgi error, before it was dumped to the screen, whether it be through perl or through a web server. We are currently using IIS 5.

Thanks
-Tom

Replies are listed 'Best First'.
Re: Trapping CGI Error
by Ovid (Cardinal) on Mar 19, 2003 at 19:56 UTC

    If you're doing this through IIS, go to you Internet Information Services console, right click on the Web site in question and select "Properties". One of the tabs in the resulting box will be a "Custom Errors" tab (or something similar). You can use that to set up custom error pages. This is more robust than trying to alter all of your scripts to output the correct page.

    Cheers,
    Ovid

    New address of my CGI Course.
    Silence is Evil (feel free to copy and distribute widely - note copyright text)

[reply]
      You can set the error page by the HTTP Error number(eg 401.1, 404). Do you know the error number is for a CGI Error?
[reply]
[reply]
[reply]
Re: Trapping CGI Error
by jasonk (Parson) on Mar 19, 2003 at 19:22 UTC

    You mean something like use CGI::Carp 'fatalsToBrowser';?

    We're not surrounded, we're in a target-rich environment!
[reply]
[d/l]
      From my understanding of CGI::Carp 'fatalsToBrowser', it outputs fatal errors to the browser. I've never used it, so I could be wrong. I don't want to out put them, I just want to trap them.

      Instead of the browser displaying 
      CGI Error
Your cgi script misbehaved by not returning...

      [download]
      I want to be able to trap that error, possibly write it to a log file, and display a nicer looking page that says something like 

      We are currently experiencing technical difficulties please try again 
+later.

      [download]
[reply]
[d/l]
[select]

        You can assign subroutines to $SIG{__WARN__} and $SIG{__DIE__} that will get called in case of warnings or dying, and do any logging you want there. See 'perldoc -f die' and 'perldoc -f warn' for information on these handlers.

        We're not surrounded, we're in a target-rich environment!
[reply]
Re: Trapping CGI Error
by ajt (Prior) on Mar 19, 2003 at 20:29 UTC

    Hi, tcf22,

    Unless they have fixed things, IIS dumps STDERR to the browser, and not to a log file - it's not very smart. This sounds like the error you are describing.

    For run time errors you have to build your own custom error handler, it's what I did. Compliation errors just generate 501s and you'll be none the wiser! If you dig deep into the evil depths of IIS it may be possible to configure a custom log with the contents of STDERR in it, but I didn't have time to find it last time, so I'd like to know if it's possible too!

    Good luck with it's other problems too.......


    --
    ajt
[reply]
Re: Trapping CGI Error
by clairudjinn (Beadle) on Mar 19, 2003 at 20:13 UTC
    		[reply]
        What you're describing is exactly the right way to handle errors that you want to trap and try to recover from. However, there is not much point in trapping errors that you can't recover from and don't want to send a specific messae for, like the database being unavailable or the disk being full. (You would want to log that the database was down, but you typically wouldn't want to tell the end user.) For those cases, letting the script die and setting a custom error page for 500 errors is the best approach.
    		[reply]

        Wrapping an eval around the entire application is a less-than-optimal solution.

        We're not surrounded, we're in a target-rich environment!
    		[reply]

    Back to Seekers of Perl Wisdom