Best Practices in Error Reporting

rubyonrails-talk
1

Newbie here. What is the best practice for implementing error reporting in a Rails application. I have an example that uses ActiveRecord::Base.logger.error. Are there any risks with this or recommendations on other implementations?

Thanks

2

There's nothing wrong with just logging errors, but in less you are really extremely diligent about monitoring your log files for errors, you're not going to notice problems until a user tells you or they snowball into bigger errors. Some 3rd party solutions include exceptional (www.getexceptional.com/) or airbrake (www.airbrakeapp.com) or the exception notifier plugin (https:// github.com/smartinez87/exception_notification). You can also roll your own by overwriting the rescue_action_in_public method

Fred

3

You can also use airbrake's gem with your own web UI via https://github.com/errbit/errbit

-philip

4

Thanks much for the response and the 3rd party solution link.

The more in detailed questions I have around best practices for error handling are:

- Where are error the message generated? In the example we have they are generated in the Model. Is this best practice - How are error messages displayed to the end user as friendly messages?

Thanks for all your help

5

Thanks much for the response and the 3rd party solution link.

The more in detailed questions I have around best practices for error handling are:

- Where are error the message generated? In the example we have they are generated in the Model. Is this best practice - How are error messages displayed to the end user as friendly messages?

Presenting errors to users is a whole different kettle of fish. The default rescue_action_in_public method just renders your 500.html page. You probably want to at least replace that with something more cuddly than the default. You might want to provide a little more information, but do bear in mind that most information about an exception or error are irrelevant to users. If there is something they can do to fix it or if it is a transient thing that will fix itself in a minute then that is useful info to them. Extra details tend to be overkill (assuming you are collecting all the error data so that you can fix things or respond appropriately when someone asks you why stuff doesn't work.

I would usually have the model let the controller know via exceptions/ return values when something has gone wrong and let the controller decide how to present that to the user (of course sometimes the controller will defer to the model for that, eg validation errors).

Fred