New to Rails? Read This

Rails
21

==============================
Rescue and Redirects

There are a lot of times that you’ll find when you perform a query on
your database that no records are found. Some people that are new to
rails might do something like:

if model.find(:all).empty?
… do something else
else
… continue with our program …
end

But, this doesn’t really help you when you have a very extensive
routine. It also doesn’t really handle ActiveRecord returns or even
logging the errors to your logs.

This is where rescue is a great feature that rails has implemented into
it. How do you use it? Here’s an example:

def get_products(product_id)
begin
@products = Product.find(product_id)
rescue ActiveRecord::RecordNotFound
logger.error("#{product_id} in products wasn’t found from
get_products."
redirect_to :action => :index
else
… continue with your routine
end
end

So, what did we do here?

Pretty simple when you look deeply at it. We have a routine that tries
to find a product by a product_id. Rescue occurs if no record is found
from ActiveRecord and a logger error is placed in your log telling you
what occurred, so you can later review and fix (if it needs fixing) the
error. It then redirects your user back to the index (or you can
specify some other redirect (redirect_to root_url OR redirect_to
controllername_path, etc.). If the rescue doesn’t occur, the method
continues on and processes your routine.

By using rescue you don’t have to interfere greatly with your model’s
core methods. Adding too much logic to your model methods might not be
a good thing. There are times when it might be necessary (methods that
involve rake tasks etc. come to mind) but overall, rescue is something
everyone new to rails should learn and implement into their apps.

I hope this helps.

Thanks.

22

On Thu, 2009-07-23 at 18:38 +0200, Ar Chron wrote:

switch between the different implemented platforms.
the existing VM, and upgraded the clone, then pulled in the application
from the source repository. Parallel environments with few headaches,
and allows straight up comparative testing.

I, too, have moved to running Windows VMs inside VMware on Ubuntu.
Works like a champ, but if VMware is not in your budget, Before that, I
used InstantRails for the same purpose. Same results.

23

Marnen Laibow-Koser wrote:

Um, WTF? That’s where logic is supposed to go. Exception handling
supplements that logic; it doesn’t replace it.
There are times when it might be necessary (methods that

involve rake tasks etc. come to mind) but overall, rescue is something
everyone new to rails should learn and implement into their apps.

I didn’t use the right wording here. What I meant was there are
different types of logic to use with your model. In otherwords, for
every method created there are probably 3 people that will do them
completely different but achieve the same result.

Remember for loops? Which logic is better to do in the model? A for
loop or an each loop? Which is better practice? This is what I was
after. You can go to an extreme on one thing and never use the simpler
approaches.

Many developers (including me!) perhaps don’t use exceptions quite as
often as they should, but I am afraid that you are encouraging the
opposite extreme – a style of programming where exceptions are used for
everything. I understand that this is not a great idea for a number of
reasons: it is said to be inefficient and hard to follow and test.

I’m not sure I follow you completely on this particular response. Are
you saying that rescue is a bad thing when you need a routine to
continue moving forward? Or, are you saying that there’s another way
(besides rescue) that should be used to do the same thing? I like
rescue. I don’t use it for everything but there are some core areas in
my app that I do use it.

24

Alpha B. wrote:
[…]

This is where rescue is a great feature that rails has implemented into
it.

Actually, it’s a basic Ruby feature.

How do you use it? Here’s an example:

def get_products(product_id)
begin
@products = Product.find(product_id)
rescue ActiveRecord::RecordNotFound
logger.error(“#{product_id} in products wasn’t found from
get_products.”
redirect_to :action => :index
else
… continue with your routine
end
end

In most cases, this would not be worth logging. Even if it is,
exception handling may not be the best way to do it. (Also, the method
is badly named, since it will only ever get one product.)
[…]

By using rescue you don’t have to interfere greatly with your model’s
core methods. Adding too much logic to your model methods might not be
a good thing.

Um, WTF? That’s where logic is supposed to go. Exception handling
supplements that logic; it doesn’t replace it.
There are times when it might be necessary (methods that

involve rake tasks etc. come to mind) but overall, rescue is something
everyone new to rails should learn and implement into their apps.

I hope this helps.

Many developers (including me!) perhaps don’t use exceptions quite as
often as they should, but I am afraid that you are encouraging the
opposite extreme – a style of programming where exceptions are used for
everything. I understand that this is not a great idea for a number of
reasons: it is said to be inefficient and hard to follow and test.

Thanks.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

25

Hello–

On Aug 3, 2009, at 12:50 PM, Alpha B. wrote:

I didn’t use the right wording here. What I meant was there are

Many developers (including me!) perhaps don’t use exceptions quite as
continue moving forward? Or, are you saying that there’s another way
(besides rescue) that should be used to do the same thing? I like
rescue. I don’t use it for everything but there are some core areas
in
my app that I do use it.

I bring a fair amount of dated knowledge to this – the “why not use
exception handling for everything” answers from the days of C++ and
the like. I learned to steer clear of exception handling in cases
where I could fairly predict an outcome.

Ruby may have a slick implementation of exception handling and
certainly does not have the baggage of unwinding through destructors
that C++ had, but an exception is a non-local jump, not to be confused
with scope exit caused by a flow of control structure. That means
someplace things like multiple scopes need to be recognized so stale
objects can be marked for garbage collection, etc. Additionally, in
the presence of a begin/rescue block, when an exception occurs, the
interpreter has to look for the closest scoped exception handling
block that declares itself as handling the specific type or generic
superset of the exception in question. This means maintaining an
ordered searchable list of these scoped blocks, thus taking up memory
for a case which is supposed to never happen, right?

So here’s my way of deciding whether to use exceptions. I ask the
questions:

“Is the result of this operation predictable?” If yes, then I test for
it, and don’t use exceptions.

“If this operation fails, is there anything I can do about it?” If the
answer is no, then I let Rails’ rescue_action_in_public take care of
things for me and get my exception_notification email. Then I fix the
bug.

“If this operation fails and there is it important and something I can
fix programatically (e.g., would financial data be corrupted or
something equally disasterous and will I have information to mitigate
the damage)?” If the answer is yes, then I’ll use a begin/rescue block.

All of this said, there is a reason exception handling is in the
language, but it’s not (IMO) the one you cite. Exception handling is
made to wrap very important operations that simply can’t fail without
at least an honest retry strategy. You know, like “user stepped on
anti-lock brake pedal and braking computer raised an exception.” What
exceptions were not specifically designed for was to facilitate non-
local jumps out of scope.

I know there will be disagreement on what I’ve said here, so I must re-
emphasize that my habits with respect to use of exception handling are
based on avoidance rooted in a pretty dated technology, C++.
Additionally, this is something of a religious issue, where you either
hate exceptions to the extreme or see no harm in them and use them
liberally. I’ve put my opinion out here in hopes it will be useful.