Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
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

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(); }

    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?
[hippo]: Yary: There are a few useful pointers in I need perl coding standards
[hippo]: ... and a boatload of good stuff in On Coding Standards and Code Reviews
[Yary]: Looking at system pm's, looks like it's "package" on the first line, then POD, then "use 5.xyz;use strict; use warnings; use modules..."
[Yary]: ah thanks for those links
[hippo]: Just bear in mind that all such ideas are subjective.
[choroba]: There might be a different standard at the shop you write the code for.
[choroba]: The order of package - (strict+warnings | warnings+strict) - modules makes sense, POD and strict-warnings order are not so important

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (11)
As of 2018-01-23 17:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How did you see in the new year?










    Results (250 votes). Check out past polls.

    Notices?