New to Rails? Read This

[bill walton-2]

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

> Älphä Blüë wrote:
> > ==================================================
> > Ruby Platforms, Rails Versions, and Other Notables
> > ==================================================
> >
> > Ruby/Rails platform upgrades:
> >
> > 1.  Download and Install your Ruby version upgrade for non-production
> > purposes only.
> > 2.  Optionally install any relevant gems or write a Ruby/Bash script to
> > switch between the different implemented platforms.
> > 3.  Read the README file and execute any tests of the gem(s) you need
> > for your Rails application against any of the relevant Ruby
> > implementations.
> > 4.  Test against the new implementations.
> > 5.  You now have a test harnass in place for your rails application.
>
> Or adopt some sort of virtualization technology, like VMware.
>
> I run an Ubuntu virtual machine for my Rails development.  When it was
> time to test out migrating Ruby and Rails to newer versions, I cloned
> 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.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@...
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

[Adam Akhtar-2]

==============================
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.
--
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@...
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

[Adam Akhtar-2]

Alpha Blue 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
marnen@...
--
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@...
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

[Adam Akhtar-2]

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.
--
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@...
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

[s.ross]

Hello--

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

>
> 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.
>

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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@...
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---