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