On Thu, Sep 12, 2013 at 12:22 PM, Paul Lynch <
plyn...@gmail.com> wrote:
> It is because I am trying to distinguish between "real bugs" and bad input
> (a 400 error) that I don't want this to be a 500 error. I have a rescue
> action that sends me an email when a 500 error occurs (though it limits the
> number it sends) because if there is a bug in the program that users are
> running into, I want to know about it. I don't want to get those alerts
> every time someone intentionally sends bad input. It seems to me that the
> convenience of having sanitize just handle the exception outweighs the
> possibility of missing bugs involving sanitize calls (which seems slight to
> me, though maybe I am not thinking of some use case).
His suggestion was not to rescue the error, it was an example of how
you could. To rescue any error in an app is asking for edge cases
unless they are specific errors for specific actions such as a
RoutingError. The proper way to handle this is to type the input and
return long before you even hit sanitize and have to rescue for: 1.)
Better performance on errors an 2.) Better ability to know how your
app is behaving.