On Thu, Sep 12, 2013 at 12:22 PM, Paul Lynch <[email protected]> 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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAM5XQnxrAW%2Bii2wwV58LzV4nQps5K1G1-nSZG0KUUKnJAHL%2BxA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
