Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: CGI Error Handling

by davorg (Chancellor)
on Dec 10, 2001 at 15:17 UTC ( #130628=note: print w/ replies, xml ) Need Help??


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


Comment on Re: CGI Error Handling
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(); }

    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

    Update amended to consider below
      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.

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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://130628]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (19)
As of 2014-09-19 16:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (143 votes), past polls