http://qs321.pair.com?node_id=130628


in reply to CGI Error Handling

I think it's important to differentiate between the different types of errors that you're handling. For errors that are caused by invalid user input, it's a good idea to create an error page that tells them what to correct in their input - probably including the current input you've got and pointing out what needs to be fixed.

For anything that is outside of the user's control (missing files on the server, invalid permissions, that kind of thing) I think that it's a waste of time creating clever error reporting pages. You're probably not going to give the user any information that will mean anything to him than the default web server error page and you run the risk of giving a passing cracker too much information.

The "vanilla" 500 Error page is fine for most purposes. Of course, there's nothing to stop you replacing it with another that better reflects the look and feel of your site.

--
<http://www.dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

Replies are listed 'Best First'.
Re: Re: CGI Error Handling
by hakkr (Chaplain) on Dec 10, 2001 at 16:55 UTC
    I like eval blocks 
    eval {
    #any code in here
    yourSub();
}
if ($@){
    # $@ contains err message if error occurs
    warn " continue with script but there has been an erro $@ \n";
    #run error handling routine
    ErrorHandle();
}

    [download]

    The average user finds a standard Apache error page v scary so I try and make an error doc for every error possible. 

     
ErrorDocument 404 /missing.html
ErrorDocument 401 /auth_error.html

    [download]

    Update amended to consider below
[reply]
[d/l]
[select]
      Two important pieces of advice.

      The first is to pick an indentation style indenting between 2-4 spaces, and then start using it. Now. Running your code through perltidy will show you what it looks like.

      The second is to call functions with explicit parameters. That means using parens. As documented in perlsub, if you use just the plain & and in a function you call another function, that other function will get the parameters to the first as arguments.

      Believe me. You may think these are picky details. But they are not. The first strongly impacts how easy it is to pick out your logic at a glance. The second is causing a subtle set of side-effects that may or may not be intended which a maintainance programmer may or may not know enough to notice.

[reply]
        thanks pure lazyness on my part inbred by auto indenting text editors and tab keys.
[reply]

In Section Seekers of Perl Wisdom