in reply to 'Clean' Error Handling from perl during CGI

I am not a web developer, so take these thoughts with some consideration.

Why not use a module like Carp to avoid use of die altogether? You'll generally get more helpful error messages this way, and then, for production you can easily switch Carp for a custom error handling package, without having to resort to handling the "real" error signals.

I would personally prefer to have errors with web pages redirected to a static or bullet-proof script by the server, rather than try to have the error-prone script handle them. You see this a lot with 404, but it may not be appropriate in situations with more subtle errors happening behind the scenes.

A good error message in your case will not tell the user anything other than, "You can't do that." If something the user has done is involved in the error, perhaps communicate this in terms that don't reveal your system's inner workings, but will allow them to understand what they need to do differently.
  • Comment on (ichimunki) Re: 'Clean' Error Handling from perl during CGI