Re: The art of error handling

I think you're checking the user input at the wrong point if you're relying on the DBI::errstr to tell you that user input is invalid.

From a security and usability stand point you should test your data long before you try and dump it into the database. I think the security part stands on it's own without further explanation.

The earlier you detect a problem the easier it tends to be to deal with it. What if this program routinely took 10 or 15 minutes to get to the point where the insert happens and DBI::errstr is populated? Your users will be upset.

Better options for detecting and reporting errors in web apps (in order of increasing ease of user interaction):

Check the format with a Javascript and pop up an alert box with the error message "Format for the DATE must be YYYY-MM-DD" Then use the javascript to set the focus to the appropriate form field (provided the browser supports it and is turned on yada yada)
Build your web form so that it is impossible for the user to enter the incorrect date. This is easier on you as a programmer and easier on your users. Use 3 select boxes: one for the year, one for the month and one for the day.
```
   Year     Month       Day
   [2000|v] [January|v] [26|v]
   
```
(bad ascii rendering as form and table tags are filtered) You get back three values that you know are acceptable and can be concatenated into a good looking date.
```
  $date = $param{year} . "-" . $param{month} . "-"  . $param{day};
[download]
```
Now that format is covered (and users aren't frustrated) use a module like Date::Manip to check if a date is _valid_ (i.e. not 2000-02-31 aka Feb 31st)

(I actually skipped one option, but it relies on your application using a really good templating system and being one cgi with a lot of conditionally generated html: It's process the page on the server and return it with the offending fields highlighted and the error message above or below the field explaining the problem. The top of the page should declare that there is a problem and to pay attention to the indicators yadda yadda yadda.)

If you continue down the road you're on now are you really prepared to grep DBI::errstr for every partial error string that could be tossed from within the database?

--
Clayton

Comment on Re: The art of error handling Download Code

Replies are listed 'Best First'.
Re: Re: The art of error handling by saucepan (Scribe) on Dec 20, 2000 at 10:03 UTC
It's true that it's often more usable to have the interface permit only valid input to be expressed--rather than accepting anything and emitting error messages later--but remember that you need to leave the server-side verification in place for security. Clayton probably knew this, but client-side error checking is risky on it's own since everything running on the attacker's machine is under his control, including his copy of your HTML and javascript. the exceptions that prove the rule	[reply]
Re: Re: The art of error handling by markjugg (Curate) on Dec 22, 2000 at 07:03 UTC
Hi Clayton, Thanks for the response. Although my question was about about error handling in general, I'm happy to discuss this specific case some more. In general I agree that's better to check the user input early on. In this case, I actually considered using 3 drop down menus to force the user to select a valid date. I chose not to do this for two reasons: 1. It was going to take longer to code. :) 2. Based on my own experience, it's faster just to type in the date than to take my hands off the keyboard to do three mouse-menu selections. So I felt like it was more user friendly (Although I realize with my solution they have the possibility of dealing with an error page which won't need to happen in the other case.) I don't think there is a security issue in this specific case-- either someone is going to input a valid date or they are not, and if they don't, I catch it. I still could have chosen to do the error checking in perl before it went in the database. Checking for YYYY-MM-DD is easy. If that was all there was to it, I probably would have done that. I also need to check to see if it's a valid date, which is not so easy. To do this I would have loaded Date::Calc at a slight speed penalty. So I thought my solution was good because it relatively quick to code and easy to maintain, it executed quickly and it was safe from a security standpoint. I agree that the solution wouldn't "scale up in well" in the sense that I don't want to be greping DBI::errstr to check for user input problems all the time. I'm more interested in the question of "In this case, I have a standard error I want to return. I want it to be easy to cause the error to be thrown by default, but I want the error to be handled a high level. How do I do that?" -mark	[reply]