If your app raises an exception not caught by your app, then Rails will log it, using it's own rules for when to log, what to log (backtrace clean), how to format the log, etc. And will then present a 500 error message.
I am rescue'ing some exceptions myself, because I can recover from them with a better user experience than a generic 500 error.
However, they still represent unexpected conditions that should not have been possible, and I still want to log them -- I want to log them just like Rails does.
One would think there would be a method in Rails I can actually call myself to do this. Alternately, if needed, if I could find where in Rails does this, I could just copy and paste duplicate the logic to do it the same way.
But I'm having trouble finding what's what in Rails regarding this stuff at all. The code is confusing, spread accross middleware as well as Rails itself, different parts that look like they're going to tell me what I need but then don't seem to, etc.
Anyone have any ideas?
Related
I'm reading active_support documentation and it says that whenever there's a controller action called, rails searches for corresponding helper class. If there's no such class, an exception is thrown, caught and possibly rethrown.
I'm curious how (in)efficient is this and should I just have empty helper classes for the sake of not throwing exceptions in the background of my code?
I'm not trying to do any kind of premature optimization, I'm just looking into internals of rails and was curious as to why would they make it so that it always throws exception when there's no helper defined.
Here's the related documentation:
http://guides.rubyonrails.org/active_support_core_extensions.html#extensions-to-nameerror
Any insights and more details would be appreciated.
Thanks!
I'm going to answer from a place of "wishful thinking", not from any particular knowledge about Rails internal code. I know (and love) that Rails was built with the busy developer in mind: it was designed by someone who hates repeating himself, with an ethos of DRY code and sensible defaults in mind.
So given that, it sounds like a horrible idea to worry about setting up empty helper classes just for the sake of making the Rails startup code more efficient. That's very opposite to the intentions that Rails was built on, and I think you can count on the community holding to those intentions going forward.
I’m building a small application, and in part of the UI you can sort some objects (persons). So when I call this url:
http://localhost:8080/addressbook/person/list?sort=name
all works nicely.
However, when I change the URL to the following, my application is throwing exceptions:
http://localhost:8080/addressbook/person/list?sort=thisisanunknowproperty
I get errors like:
Class
org.hibernate.QueryException
Message
could not resolve property: thisisanunknownproperty of: persons.Person
This is really not what I want, of course. The application should just not sort, and not throw exceptions like this. But how do I prevent this behavior from happening?
Thing which come to mind is that I build something in which checks if the property is a member of the allowed properties to sort, but I'm wondering if there is anything out of the box for this which I missed?
As I mentioned via email, take a look at Grails Command Objects which are based around the Spring Validation API.
The hard and fast rule is never, ever blindly accept user input. In many frameworks, Grails included, this has exposed some nasty security holes.
If I get 500 errors in my server logs, I would prefer to store them to the DB in a table like server_errors (id, user_id, created_at, build_version, error_code, error_output).
My initial idea is to just run a script that constantly greps log/production.log for errors and stores them to the DB as they come in, but this seems like an ugly solution and gets unwieldy when you consider things like log rotation etc.
This seems like a common enough feature that there should be a gem for it, or some standard functionality built into Rails (2.3.12) so I was hoping that somebody might know of something like that. Or could suggest a better methodology if you can think of one.
Most folks use exception_notification, NewRelic RPM, or AirBrake (formerly known as Hoptoad) to see their exceptions.
If you would like to roll your own, take a look at how exception_notification does it. It uses a middleware component to catch the exceptions. You could catch the exceptions in your own custom middleware, then save the information to the database table you described above instead of emailing it.
For background queueing, see how resque does it.
If you're using Rails 2.3, you should use the 2-3-stable branch of exception_notification instead of the master branch.
I've got some strange errors happening in my rails app and I'm trying to log better errors instead of the whole stack of passenger stuff that I don't care about. I thought I would do this with a Rescue clause and explicit error handling, like logging the params hash. But I'm concerned if this would interrupt any rollback that is happening. For that matter, I'm assuming rollbacks automatically occur when an error occurs as part of the normal rails error handling, but I haven't been able to find that documented anywhere. I'm using Dreamhost with MySQL, so I thought transactions and rollbacks were happening there.
This is not very advisable (to put a big begin-rescue on your code).
Why don't you use backtrace silencers? (from Rails 2.3)
http://afreshcup.com/home/2008/11/29/rails-23-backtrace-silencing.html.
From release notes:
Rails automatically adds silencers to
get rid of the most common noise in a
new application, and builds a
config/backtrace_silencers.rb file to
hold your own additions
If you use an earlier version of Rails, use http://github.com/thoughtbot/quietbacktrace.
In my Rails app, I changed my model's find method to search into the cache before looking into the database, but I sometime get this error:
Memcached::ServerIsMarkedDead
While waiting for Memcached server to be up again, how should I handle this error and force Rails to search into the database?
Thank you,
Kevin
You should be able to just rescue the exception and search the database in that case.
Rails.cache.fetch encapsulates this pattern in a more generic way, and you may want to look into that instead of hacking find, which is likely to bite you soon when Rails 3 comes out.