# New to Rails? Read This **URL:** \ **Category:** Rails\ **Created:** [July 9, 2009, 7:14pm UTC](https://www.ruby-forum.com/t/new-to-rails-read-this/171825 "2009-07-09T19:14:48Z")\ **Posts on this page:** 5\ **Page:** 2
**Author:** ![elricstorm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/da6949/32.png) [@elricstorm](https://www.ruby-forum.com/u/elricstorm)\ **Post date:** [August 3, 2009, 3:41pm UTC](https://www.ruby-forum.com/t/new-to-rails-read-this/171825/21 "2009-08-03T15:41:33Z")
# ============================== 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. ---
**Author:** ![elricstorm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/da6949/32.png) [@elricstorm](https://www.ruby-forum.com/u/elricstorm)\ **Post date:** [July 23, 2009, 6:53pm UTC](https://www.ruby-forum.com/t/new-to-rails-read-this/171825/22 "2009-07-23T18:53:23Z")
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. ---
**Author:** ![elricstorm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/da6949/32.png) [@elricstorm](https://www.ruby-forum.com/u/elricstorm)\ **Post date:** [August 3, 2009, 9:50pm UTC](https://www.ruby-forum.com/t/new-to-rails-read-this/171825/23 "2009-08-03T21:50:31Z")
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. ---
**Author:** ![elricstorm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/da6949/32.png) [@elricstorm](https://www.ruby-forum.com/u/elricstorm)\ **Post date:** [August 3, 2009, 5:53pm UTC](https://www.ruby-forum.com/t/new-to-rails-read-this/171825/24 "2009-08-03T17:53:36Z")
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](http://www.marnen.org) removed\_email\_address@domain.invalid ---
**Author:** ![elricstorm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/da6949/32.png) [@elricstorm](https://www.ruby-forum.com/u/elricstorm)\ **Post date:** [August 4, 2009, 12:13am UTC](https://www.ruby-forum.com/t/new-to-rails-read-this/171825/25 "2009-08-04T00:13:52Z")
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. [Previous page](https://www.ruby-forum.com/t/new-to-rails-read-this/171825.md?page=1)