http://almosteffortless.com/2007/10/08/graceful-404s-in-rails-20/

Hmm, this is strange. I was 100% positive that the standard behavior of Rails in the production environment was to return a 404 on a RecordNotFound. I was under the impression that was the whole idea behind whiny_finder (which I didn’t write).

This backs me up:
http://shifteleven.com/articles/2006/12/03/trusting-in-exceptions-to-do-what-they-do

However, when I looked at the source for rescue_action_in_public here: http://api.rubyonrails.org/classes/ActionController/Rescue.html there is no mention of RecordNotFound. It handles RoutingError and UnknownAction exceptions, but no mention of RecordNotFound.

I guess the behavior I am seeing is a mixture of whiny_finder and exception_notification (available here: http://dev.rubyonrails.org/svn/rails/plugins/exception_notification/ ). The exception_notification plugin (heavily recommended) adds RecordNotFound as an exception that generates a 404.

Looking at Edge Rails trunk ( http://dev.rubyonrails.org/svn/rails/trunk/actionpack/lib/action_controller/rescue.rb at rev 7026) it seems as though Edge Rails has RecordNotFound as an automatic 404, although I didn’t read too deeply. I’m guessing that’s why exception_notification was updated to have the same behavior.

I will update the article to mention exception_notification, Edge Rails, and/or how to update rescue_action_in_public to translate RecordNotFound into a 404. Doing any of those should result the desired behavior.

I guess it take 15 minutes instead of 10

Thanks for the catch, Tony.

ActiveRecord::RecordNotFound will return a 500 response to the client. The same exception and response that whiny_finder returns.

I actually take back my arguments against whiny_finder (I got a chance to read through it’s code) — you never get to 404s. In fact, it’s used to raise more 500s on exceptional “searches”

Can you please explain what you mean by “raise a 500 exception and reroute to 404″? I’m not clear on what a 500 exception is. I know what a 500 response code is, but the whole point of the article is to convert 500s to 404s (where appropriate…)

Assuming you mean “raise an exception that would generate a 500″, then I would have to disagree, as it seems overly complicated. In most cases you would raise the exception, then immediately catch it, then reroute to a 404. If you’re vehemently opposed to whiny_finder and RecordNotFound, then just use the one-liner you posted earlier.

Also, can you please post a link to the Rails Docs you’re referencing regarding the proper usage for find? I’d like to read this. The only stuff I’ve read on find() is from the RDoc for ActiveRecord::Base (located here: http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M000992 ), and I can’t find anything specific about when to use find() vs find(:first) vs find_by_().

My stance is that you raise a 500 exception and reroute to 404.

If you’re rewriting all find_by_ to find_by_! (bang) anyways, why not skip the plugin and follow Rails Doc’s on the proper usage of find vs find(:first) ? Sure, it’s a few more characters.. but you’d be using proper Rails, *and* actually logging all your real 500s.

The following link is an example from Obsidian Portal:
http://www.obsidianportal.com/campaign/kensing

“kensing” is the slug for a campaign, and it’s not technically the ID. Still, for all intents and purposes, it is an ID because it’s guaranteed unique.

So, in the controller for this we have:
Campaign.find_by_slug(params[:slug])

Anyways, if a user writes this down and hands it off to a friend as:
http://www.obsidianportal.com/campaign/kesning (note the typo in the slug) then the URL they created effectively requests a non-existent id. It’s not a search, but simply a request for something that’s not there. If they post this URL on the web somewhere then both humans and bots will find it and try to follow it. I wish I were smart enough to write something that recognizes the typo and takes them to the right place, but for now I’ll settle for the 404.

By using whiny_finder, I can just use find_by_slug! (bang) and it will automatically result in a 404 if the slug is not found. The one-liner you wrote will work as well, but it has to be done every time you do a similar find. whiny_finder effectively collapses that particular one-liner into the find() method itself. For places where it’s inappropriate, just use the regular, non-bang find().

render :file => “public/404.html”, :status => 404 and return if @result.nil?

The case here is _not_ a 404 — it’s an exception due to corruption in data. How’d you manage to pass a non-existent id to find in the first place?

Robots don’t enter obscure ids, just follow your internal links. Users do enter arbitrary data… but then it’s a search, and should be treated as such.

Anyways, raising an exception on a user search that resulted in no matches will hide all the real 500s that you probably should be fixing.

Assuming you’re checking for nil on user input, what happens when you search for something and get nil? What should you do then? You could redirect them to a page warning them that it wasn’t found. But wait, isn’t that what a 404 page is for?

Or, you can use whiny_finder to do the checking for you and throw the RecordNotFound exception, which automatically takes them to the 404 page. The end result is pretty much the same.

I don’t recommend masking 500s as 404s, but the case being dealt with here _is_ a 404. It only becomes a 500 if you don’t (or forget to) do any checking on the value returned from find() and then try to execute an operation on it.

If you are handling user input, you can’t be sure that valid information is supplied, so you search for it.

Model.find(:first, :conditions => … )

You either get the first record that matches, or nil. Which is alright, because you check for such kind of stuff, right?

Masking your 500s with 404s is like saying “I write _really_ sloppy code. And actively ignore it!”