Obviously, the next step is then to use a custom 'error' handler that you use instead of die. It can still dump the error message to error.log, but you can at least exit the program cleanly with a somewhat informative error to the user. However, this then brings up another problem: while certainly it's best to try to collect all system resource calls to as early as possible in the program before output is sent, this is not always possible particularly in database usage, and thus, you'd have printed a lot of your page, and then suddenly have this error message in the middle of it.
So the next logical step would then be to print all data that would have normally gone to STDOUT from the CGI call to a string or other temporary cache which is then sent all at once at the end of the CGI program to STDOUT. Errors that occur before this point can then be shown to the user on a 'clean' page even if they occured mid-CGI processing. While this is probably the best, you then introduce a big problem when programming as you could easily miss adding the cache storage area in print statements, or as some packages do like Template Toolkit, forget to give them an alternate target for some operations. This moves the problem more onto the programmer's shoulders than the user, but I can see it being very potentally bug-ridden.
So my question is basically, at what point is the error handling method typcially accepted by the user and by the programmer together? My inclination from other sites is that the somewhat descriptive but possibly in the middle of the page error message is typically acceptible by both programmer and user, but that's my current opinion. I'd be worried about all the errors that I could introduce by switching to the cache'd method.
The other related question: is it wise to necessarily let the user know directly of the error message? Some are sufficiently descriptive that while they easily narrow down the problem for the programmer, they could also be used by a malicious cracker or user to harm your system if they tried. Other non-malicious users will also just see a blob of undecipherable text on the screen, and will most likely simply shrug. I'd like to provide at least some clue as to what happened (say 'error in the database system', 'error in file operations'), which fortunately can be done if one handles their own errors instead of with die (pass in a keyword that indicates where the error was). Probably more importantly, I would want to include the localtime of the error and any other possible parameters that may or may not show up when I write to the error.log. Has anyone found any good guidelines for letting the end user know what's wrong?
In reply to 'Clean' Error Handling from perl during CGI by Masem
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |