I’m going to illustrate how scopes can be used with a simple example.

A Product Application

I’ve created a very simple application to manage products. All the basic functionality is there – view/create/edit/delete.

The controller code for viewing the list of products is very simple.

def index
  @products = Product.all
end

You’ll notice (in the screenshot) that each product has a status – ‘Available’ or ‘Coming Soon’. Let’s imagine that the user wants to be able to view all Available products. How might we accomplish that?

The easiest way to do this would be to add a separate route and action which simply filters the products to only those with the correct status. First, let’s add the route.

get 'products/available' => 'products#available', :as => 'available_products'

Now we only need to add the controller action.

def available
  @products = Product.where(:status => 'Available')
  render 'index'
end

This certainly works, but there’s a cleaner way of doing this.

Using a named scope

Instead of using the where method in the controller, we can move the behavior to the controller. We could create a class method to expose this filter, but Rails has a much nicer way – named scopes. Let’s see what that looks like.

class Product < ActiveRecord::Base
  scope :available, where(:status => 'Available')
end

Now our controller code is much cleaner and easier to read.

def available
  @products = Product.available
  render 'index'
end

And everything still works exactly as before. Hurrah!

Using default scope

As I mentioned, we also have the functionality to delete a product. However, we might not want to delete the record out of the database – we simply want to mark it as deleted. (There are a number of reasons why we might choose to do this – for example, we might have transactions linked to a product)

Here’s the code for deleting a product.

def destroy
  @product = Product.find(params[:id])
  @product.update_attribute(:deleted, true)
  redirect_to products_path
end

Let’s take another look at our list of products.

The deleted products are showing up in our regular list! While this makes sense (since we’re simply flagging them as deleted – not actually deleting them), this is definitely not what we want. So how do we fix that? One way would be to update all our queries to include :deleted => false. As you probably guessed, Rails has a neater way of doing this – using default scope.

class Product < ActiveRecord::Base
  default_scope where(:deleted => false)
  scope :available, where(:status => 'Available')
end

As the name implies, default_scope changes the default list of products being returned. Our list of products no longer shows deleted products. For example, Product.all will exclude deleted products. Pretty neat.

What if we want to bypass the default scope and actually get all products? For example, I might want to have an admin function that lists all unavailable products – meaning products which have their status set to something other than Available. We can do that by using the unscoped method.

def unavailable
  @products = Product.unscoped.where('status <> ?', 'Available')
  render 'index'
end

Pretty cool.

Conclusion

This is one of those pieces of functionality that you probably won’t miss until you know it’s around. It can definitely clean up your code and make it a bit more readable. I would probably be wary of using default_scope, but in certain scenarios it probably makes sense.

If you would like to play around with this code you can find it on Github. Happy coding.

There is a massive amount of overlap between these two approaches – they’re implicitly linked. A large part of making something easy to use is to make it visually appealing, and a large part of making something visually appealing is to make it easy to use! I try to think of it as two different targets within user interface design. Design tends to focus on the visual appeal as the end goal, while user experience tends to focus on ease-of-use as the end goal. The key word here is focus – I’m not saying that design doesn’t consider ease-of-use and vice versa.

Why is this distinction important? While these two approaches have a very similar goal in mind, they follow very different development cycles. Most design firms will happily create the entire design up front, before the application is anywhere near completion. User experience – on the other hand – can’t guarantee the design up front and will evolve the design over time. The design will evolve as the user experience is refined and improved.

Case in Point

The Flight Card iPhone app is a good example of this distinction. It’s one of the best-looking apps out there. Just look at it – absolutely stunning. The fonts, colors, layout – everything is just perfect. You would think this would be one of the top-selling apps out there.

Not quite. A mere three stars out of 20 reviews? What went wrong? Let’s take a look at some of the reviews.

This app is quite visually appealing, but it has some issues that make it harder to use. You cannot add trips more than 3 days in the future (hard when you want to put an literary in). You can’t swipe between flights.

First, the app is stunningly beautiful. It’s simply a joy to look at. But it’s missing some basic functionality. First, there is no way to swipe between cards. You need to menu back to list view and choose the next card. Not so big a deal except for the page dots at the top. You can tap the dots and they will change as if you’re changing cards, but you don’t change cards. And the dots are maddeningly hard to hit.

It seems that while the visual design is off the charts, the user experience is terrible. (I haven’t used the app, I’m only going on what the reviews say) This is perhaps an extreme example, but I’m trying to point out that a bad user experience means a bad app.

Guarantees

At the moment the popular approach is the design approach. No doubt about it. I think from a client’s point of view this is regarded as the ‘safe’ approach. Because we start out with the design and do pretty much the entire design up front it’s guaranteed – we have a good idea of what the final application will look like, even though we don’t know exactly how it will work.

The user experience approach is perhaps considered to be the ‘risky’ approach. We don’t have a good idea of what the application will look like – we only know that we will get much more input into the design and the user experience as the application is built. We’re almost guaranteed to end up with a better user experience, but because we don’t have a good idea of what the final application will look like, it feels like we’re taking a risk.

History repeating itself?

I think we’re facing a similar challenge to the one we faced 10 to 15 years ago – when agile started being introduced. Clients felt safe with the waterfall approach – all the planning being done up front meant that we had a very good idea of what the software would look like in the end. Then agile came along and suggested that the initial idea is less important, and we should rather focus on refining this idea as we go along.

Selling agile 10 years ago was probably similar to selling the user experience today. I do think that approaching the user interface from a user experience point of view is inevitable – it simply makes the most sense from both the user’s and the client’s perspective.

To illustrate this, I’m going to recreate a problem I recently came across when working on RapidFTR – one of the social projects I’m involved in at ThoughtWorks.

Let’s see some code

To start off, I’m going to extend the example I was using in my last post about routing. I’m basically managing products – I’ve created a Product model, a Products controller and I have a single entry in my routes configuration.

resources :products

When I run rake routes I get the following list of routes.

Right, now we have a new requirement – we need to be able to mark a product as a duplicate. We might have 2 admin users adding products and somehow we end up adding the same product twice. We don’t want to delete it (since some users might have bought the duplicate, etc) so we’re only going to mark it as a duplicate and link it to the non-duplicate product.

At the moment I can perform two actions on each product – view and edit. So I now want an additional action – mark as duplicate. This should take me to a page where I can select the non-duplicate version of the product.

Doing it the wrong way

Sounds easy enough – I’m probably going to need two additional actions on my controller – one to view the page and one to handle the page being submitted. To get started, let’s add 2 new routes.

get 'products/duplicate/:id' => 'products#new_duplicate', :as => 'new_duplicate'
post 'products/duplicate/:id' => 'products#create_duplicate'

Running rake routes reveals that we now have two additional routes.

Now I just need to add two method to my Products controller. This could be done better (moving some of the functionality into the Product model, for example) – I put all the code into the controller to make it clear what’s going on.

  def new_duplicate
    @product = Product.find(params[:id])
    @all_products = Product.where(['id <> ?', params[:id]])
  end

  def create_duplicate
    @product = Product.find(params[:id])
    @duplicate_of = Product.find(params[:duplicate_of_id])
    @product.duplicate = true
    @product.duplicate_of = @duplicate_of.id
    if @product.save
      redirect_to products_path
    else
      render 'new_duplicate'
    end
  end

We can mark a product as duplicate! Hurrah! Are we done?

Doing it the right way

While this code certainly works, I don’t think it’s really the Rails way of doing it. It’s actually quite easy to end up with too many methods on your controllers – to avoid this, it helps to think in terms of resources, rather than models and controllers.

In this case, we can think of duplicates as being an additional resource. So instead of marking an existing product as a duplicate, we’re creating a new duplicate resource. As you’ll see, this enables us to use the regular REST verbs – new, create, edit, update, etc. Enough talking, let’s see how this would actually work!

I’m going to start off by changing the routes. Here I’m using a nested resource.

resources :products do
  resource :duplicate, :controller => 'duplicates', :only => [:new, :create]
end

Now our routes look a bit nicer.

You’ll notice that our route now includes the :product_id, instead of just adding an id at the end of the route. This enforces the idea of a duplicate resource, which is available on product resources.

Now I only need to move my two actions to the newly created Duplicates controller.

class DuplicatesController < ApplicationController
  def new
    # same code as before
  end

  def create
    # same code as before
  end
end

More Examples

I first came across this concept in The Rails 3 Way – the common example seems to be in creating sessions. Instead of adding login and logout methods to the Users controller, we can think of sessions being a resource. So we might end up with a Session controller with new, create and destroy actions. Which actually makes a lot more sense.

If you would like to have a look at the code you can find it on Github. Happy coding.

defined? name
# nil
name = "Bob"
defined? name
# "local-variable"

However, I remember reading something in The Rails 3 Way about not being able to do this in partial views. Apparently there is an implementation restriction in the rendering system, and we need to use the local_assigns hash.

<% if local_assigns.has_key? :name %>
  <p><%= name %></p>
<% end %>

I tried to find out what exactly the restriction is, but the only reference I could find was in the Rails API (under Passing local variables to sub templates).

Testing using defined? headline will not work. This is an implementation restriction.

I guess it’s just one of those things we need to remember. Happy coding.

One of the discussions which often comes up is whether or not something qualifies to be a user story. More specifically, we might want to introduce a more technical story – which means we would have to choose between creating a new user story or lumping it with one of the existing stories. While there is no right or wrong answer, I like the idea of viewing user stories as a planning tool – we shouldn’t be afraid of creating a story to aid in our planning.

While reading the RSpec book I came across a very good test to determine if something qualifies as a user story. According to Bob Koss a user story must have the following characteristics:

Have business value. To me, this is the key when introducing more technical stories. A feature doesn’t necessarily have to directly be used by a user in order to qualify as a story. It only needs to add business value.

Be testable. We need a set outcome, and therefore we need to be able to test that outcome. Otherwise we don’t know when the story is complete.

Be small enough to implement in one iteration. This speaks to the need to balance implementation concerns with requirements. We want to keep the stories small, while still keeping a single piece of functionality as coherent as possible. As I said, it’s a real art.

While creating good user stories is easier in theory than in practice, I really like the idea of evaluating stories against these characteristics. Happy coding.

Programming Ruby is probably the most well-known book in the Ruby world. I guess I’m a little unsure as to the target audience for this book, but based on the amount of recognition it has received it seems to be aimed at pretty much anyone who codes in Ruby.

There are several points in the book where the author gives you the option of skipping past a particularly difficult section, which would be very helpful to newcomers to Ruby will still making it useful to more experienced developers.

The Good

I started reading this book to learn Ruby. I already knew a bit of Ruby at that point, but I wanted to really understand the different concepts and functions of the language. This book does work pretty well for that approach – new concepts are introduced in an order that makes it easy to understand and the explanations are straightforward and backed up by good examples. The first section of the book serves pretty much as a tutorial to the Ruby language.

After reading the first 100 pages or so I abandoned the book and started coding a few simple examples. I then moved on to Project Euler and solved a fair number of the problems with my new Ruby skills. This is probably the approach I would recommend – you can try to read the whole book cover to cover, but you’re probably better off writing more code as soon as you feel comfortable.

All the sections in this book are incredibly detailed and well-written. The amount of research that must have gone into this is very impressive. I only read the latest version (aimed at Ruby 1.9), but from what I read online almost 50% of the book was modified from the previous version.

The Bad

Similar to The Rails 3 Way, this book is long – more than 900 pages in all! I don’t think anyone will read this cover-to-cover, but even reading everything up to the reference section is more 400 pages. While this makes the book great from a reference point of view, I did find everything past the first (tutorial) section to be a bit long-winded. For example, I don’t really see the need to know all 8 aliases for the exit command in IRB (the Interactive Ruby Shell).

I also found some of the examples to be a bit confusing – especially some of the examples around testing could probably be improved. (I’ve found this to be the case for quite a few books, so maybe I’m just overly fussy)

Conclusion

This book is incredibly well researched and covers pretty much everything in the Ruby world. While it does have a very good introductory section I think the main benefit to this book is as a reference guide.

I’m a bit in two minds about using a book as a reference guide in today’s world where most reference material is simply a Google search away, but from what I’ve seen this book would work very well in complementing online reference material. It’s simply a matter of all the topics being very detailed and well researched.

A Simple Example in JavaScript

Let’s first look at a simple JavaScript example.

var widget = {}

widget.name = "Wobble"
alert(widget.name)

widget.surname = "Bobble"
alert(widget.surname)

This will run without any problems. If you try to get the value of a property that doesn’t exist JavaScript will simply return undefined. If you try to set a property that doesn’t exist JavaScript will create that property and set the value. JavaScript will complain when you try to invoke a method that doesn’t exist.

If I recall correctly, dynamic objects in C# 4.0 will function the same way – you can add properties to a dynamic object without problems, but invoking a method will raise an error. (It’s been a while since I worked in C#, so don’t quote me on that)

Ruby doesn’t have the concept of properties, so in the following snippet of Ruby code,

widget.name = "Wobble"

Ruby is actually looking for a method called name= and passing the string “Wobble” as a parameter.

A Simple Example in Ruby

Let’s try the same example in Ruby.

class Widget
end

widget = Widget.new
widget.name = "Wobble"
puts widget.name

As you might expect, Ruby raises an error saying there is no name= method on this object.

There are a couple of ways we can get around this limitation. The simplest is probably to add a name accessor to the class.

class Widget
end

widget = Widget.new
class Widget
  attr_accessor :name
end
widget.name = "Wobble"
puts widget.name

As you can see from the example, Ruby allows us to add accessors for a @name instance variable to the class. The attr_accessor method (also called a Macro) will add the necessary methods to access this attribute – in other words, it’s similar to adding the following two methods:

def name
  @name
end
def name=(val)
  @name = val
end

It’s important to know that the attr_accessor method doesn’t actually create the @name instance variable – it will be created the first time we access it.

Using method_missing

Ruby also allows us to define a method_missing method (also called a Hook) which will be invoked when a method is not found (as you might deduce from the name). It has a pretty simple signature:

def method_missing(name, *args, &block)

So we have the name of the method being called (passed as a symbol), the arguments passed as a splat array, and a block.

We can now put this to use to allow us to dynamically access any instance variable.

class Widget
  def method_missing(name, *args, &block)
    if name =~ /.*=$/
      instance_variable_set("@" + name.to_s.chop, args[0])
      return args[0]
    end
    if name =~ /.*[^=]$/
      return instance_variable_get("@" + name.to_s)
    end
    raise "I can't figure out what you're trying to do"
  end
end

widget.surname = "Bobble"
puts widget.surname

Conclusion

I definitely wouldn’t advocate using this type of code in a real project, but it’s interesting to see what’s possible.

If you want to play around with my example you can find it here. Happy coding.

A Simple Example

In this example we have a simple Customer class.

class Customer
  def initialize(first_name, last_name)
    @first_name, @last_name = first_name, last_name
  end

  def append_name_to_file(file)
    file << @first_name << " " << @last_name
  end
end

Let’s go ahead and write a test for the append_name_to_file method. (I’m not a fan of doing testing this way – we really should write the test first, but let’s ignore that for a moment)

One way to test this would be to create an actual temporary file and pass that to the Customer object.

class TestCustomer < Test::Unit::TestCase
  def test_customer_writes_full_name_to_file
    customer = Customer.new("Mark","Twain")
    File.open("Output.txt","w") do |file|
      customer.append_name_to_file(file)
    end
    File.open("Output.txt") do |file|
      assert_equal(file.read, "Mark Twain")
    end
    File.delete("Output.txt")
  end
end

If I run the test I get the familiar success output. Hurrah!

That’s an ugly test

Ok, so this test isn’t all that pretty. For one thing, there’s quite a lot of work going on just in order to get the test to run and to make sure the file we create is removed at the end. Even worse, when the test fails the final line of the test will not get executed and the temporary file is never removed! Using my knowledge of Exceptions I can fix that easily enough:

class TestCustomer < Test::Unit::TestCase
  def test_customer_writes_full_name_to_file
    begin
      customer = Customer.new("Mark","Twain")
      File.open("Output.txt","w") do |file|
        customer.append_name_to_file(file)
      end
      File.open("Output.txt") do |file|
        assert_equal(file.read, "Mark Twain")
      end
    ensure
      File.delete("Output.txt")
    end
  end
end

I’ve taken care of the file being left behind when the test fails, but my test code is still pretty ugly. The author of the Pickaxe book now argues that we don’t really need to pass a file to the append_name_to_file method – we simply need to pass something which acts like a file. How about using a simple array?

class TestCustomer < Test::Unit::TestCase
  def test_customer_writes_full_name_to_file
    customer = Customer.new("Charles", "Dickens")
    fake_file = []
    customer.append_name_to_file(fake_file)
    assert_equal(["Charles", " ", "Dickens"], fake_file)
  end
end

The test passes, and the code is much simpler. Are we done?

The Implementation changes

Not quite. Let’s say I’m working on the Customer class and I decide that I don’t really this C++ syntax – I would prefer to do a simple formatted string.

def append_name_to_file(file)
  file << "#{@first_name} #{@last_name}"
end

Notice that I didn’t change the behavior, but when I run the test…

Uh-oh. The problem stems from the fact that we were testing the underlying implementation details, not the behavior. I didn’t check that the Customer object can write to a file, I tested that the Customer object uses the << method to write 3 different strings to the file object I pass to it.

One way to fix this would be to stop using an array and pass in a string. Let’s try that.

class TestCustomer < Test::Unit::TestCase
  def test_customer_writes_full_name_to_file
    customer = Customer.new("Jane", "Austen")
    fake_file = ""
    customer.append_name_to_file(fake_file)
    assert_equal("Jane Austen", fake_file)
  end
end

Once again our test passes, and the code is even simpler. Are we done? Well, let’s see – another developer is now working on the code and he/she is of the strong opinion that the only correct way to write to a file is to use the File#write method.

def append_name_to_file(file)
  file.write "#{@first_name} #{@last_name}"
end

And we’re back to square one. Once again, I didn’t change the behavior of the method, but changing the implementation has broken the test. This is an example of fragile unit tests – tests which break when the code under test is still functionally correct. This is often a symptom of poorly designed tests.

What’s the Answer?

So what’s the answer? Should we go back to using a temporary file? (Using a temporary file worked for all three implementations) Not really. I think in this case the problem is actually poor design and we’re struggling to test the code as a result. From an object-orientated perspective it doesn’t really make sense for a Customer object to have an append_name_to_file method. Any time you see a method taking an object and then doing something to it, it’s usually a code smell.

Let’s try and refactor this code. Instead of the Customer writing something to a file, I think it makes more sense for a Customer to have a method that returns their full name.

class Customer
  def initialize(first_name, last_name)
    @first_name, @last_name = first_name, last_name
  end

  def full_name
    "#{@first_name} #{@last_name}"
  end
end

Now it’s straightforward to write a test.

class TestCustomer < Test::Unit::TestCase
  def test_customer_has_full_name
    customer = Customer.new("John", "Milton")
    assert_equal("John Milton", customer.full_name)
  end
end

That’s only ONE solution

Ok, what should we do when we really do need to test interaction with a file?

Unfortunately, there is no silver bullet or golden rule here. If there was, this wouldn’t be an issue. We could possibly mock the behavior or maybe we really do need to use a temporary file. The only golden rule (in my opinion) is that we need to make sure we’re testing the right thing – behavior, not implementation. This leads to better, more maintainable tests – which will pay massive dividends in the long run.

If you want to play around with my example you can find it here. Happy coding.

Let’s see some code

This is much easier to explain with an example.

def get_number
  rand(100)
end

random_numbers = catch (:random_numbers) do
  result = []
  10.times do
    num = get_number
    throw :random_numbers if num < 10
    result << num
  end
  result
end

p random_numbers

The catch keyword defines a block with a given name. The block is processed normally until a throw statement is encountered.

When a throw statement is encountered Ruby will look up the call stack for a catch statement with the corresponding symbol. It will then unwind the call stack up to that point and terminate the block.

In this example the block will have two possible return values. If no number under 10 is generated the throw statement will never execute and the array of random numbers will be returned. If the throw statement does execute the block will simply return nil. Ruby also allows us to override this behavior – for example, instead of returning nil I might choose to return an empty array. We can do this by specifying a second parameter to the throw statement.

random_numbers = catch (:random_numbers) do
  result = []
  10.times do
    num = get_number
    throw(:random_numbers, []) if num < 10
    result << num
  end
  result
end

Performance

One of the reasons why it’s possibly not a good idea to overuse exceptions in your code is performance. Every time you raise an exception Ruby has to build a stack trace. If your exceptions are exceptional (as they should be) this won’t be a problem. However, if you’re using a large number of exceptions in a tight loop it could have a negative impact on performance. I’m assuming that a catch-throw block doesn’t need to create a stack trace – let’s see if we can get a rough idea of the performance impact.

start = Time.now
10_000_000.times do |i|
  begin
    raise StandardError, "Error #{i}"
  rescue StandardError => error
    error.inspect
  end
end
puts "Raise&Rescue Operation took #{Time.now - start} seconds"

start = Time.now
10_000_000.times do |i|
  catch (:the_loop) do
    throw :the_loop
  end
end
puts "Catch&Throw Operation took #{Time.now - start} seconds"

As I mentioned, these are very rough performance estimates, but there does seem to be a significant performance difference between using exceptions and using a catch-throw block.

Conclusion

The catch-throw block seems to be a lightweight error handling mechanism – useful when you want to jump out of a nested construct during normal processing. The performance figures point to the same conclusion.

If you want to play around with my example you can find it here. Happy coding.

Basics First

To illustrate Exceptions, I’ve created a very simple class that simulates interaction with a remote resource.

class RemoteResource

  def initialize
    @users = Hash.new
    @users["Malcolm"] = "password1"
    @users["Angus"] = "password1"
    @users["Phil"] = "password1"
    @users["Cliff"] = "password1"
    @users["Brian"] = "password1"
  end

  def create_connection(username,password,secure=false)
    unless @users[username] && @users[username] == password
      raise ArgumentError.new("Invalid username or password")
    end
    raise SecurityError.new("Secure connections are unavailable") if secure
    @connection_initialized = true
  end

  def get_resource
    unless @connection_initialized
      raise SecurityError.new("A connection has not been established")
    end
    raise StandardError.new("An unknown error has occurred") if rand(3) == 0
    "Widget #{rand(11)}"
  end

end

Let’s see what happens when we raise a simple exception.

remote_resource = RemoteResource.new
remote_resource.create_connection("Kurt","password1")

As you would probably expect, our little application exits immediately and reports the type and message of the exception that was raised. So far so good.

Handling Exceptions

Let’s see how we handle an exception.

remote_resource = RemoteResource.new
begin
  remote_resource.create_connection("Kurt","password1")
rescue Exception => error
  print "Could not create connection: #{error}\n"
end

Pretty neat. This is probably not very good code, since we’re handling the global Exception class which is bad practice – we should try to handle only specific Exception classes.

remote_resource = RemoteResource.new
begin
  remote_resource.create_connection("Malcolm","password1", true)
rescue ArgumentError => argument_error
  print "Could not create connection: #{argument_error}\n"
rescue SecurityError => security_error
  print "Could not create secure connection: #{security_error}\n"
end

We can also handle multiple Exception classes in one block.

remote_resource = RemoteResource.new
begin
  remote_resource.create_connection("Malcolm","password1", true)
rescue ArgumentError, SecurityError => error
  print "Could not create connection: #{error}\n"
end

Ensure code is executed

We can also ensure that a block of code is executed – for example, we might want to add some logging code around the accessing of the remote resource.

remote_resource = RemoteResource.new
remote_resource.create_connection("Malcolm","password1")
print "Connection created at #{Time.now}\n"
begin
  result = remote_resource.get_resource
rescue SecurityError => error
  print "Error using connection: #{error}\n"
ensure
  print "Resource released at #{Time.now}\n"
end

As the name implies, ensure ensures that a certain block of code is executed – as you can see from the output. C# users will immediately recognize a strong similarity to the finally keyword in .NET.

Ruby also introduces the else clause – this will only execute if no errors were encountered. The else clause must go before the ensure clause and after any rescue clauses.

remote_resource = RemoteResource.new
remote_resource.create_connection("Angus","password1")
print "Connection created at #{Time.now}\n"
begin
  result = remote_resource.get_resource
rescue SecurityError => error
  print "Error using connection: #{error}\n"
else
  print "The connection was accessed without any errors\n"
ensure
  print "Resource released at #{Time.now}\n"
end

This is probably quite useful in certain scenarios.

Retry the block

Ruby also allows us to correct the cause of the exception and retry the block. For example, since my remote resource is a little unstable I might choose to retry the block until the resource is returned.

remote_resource = RemoteResource.new
remote_resource.create_connection("Angus","password1")
begin
  result = remote_resource.get_resource
  print "#{result}\n"
rescue SecurityError => error
  print "Error using connection: #{error}\n"
rescue StandardError => error
  print "Error accessing remote resource - #{error}\n"
  retry
end

As you might imagine, it’s one of the easiest ways of creating an infinite loop so use with care. In fact, I actually managed to create an infinite loop while writing this post!

Conclusion

As someone coming from C# the Exception handling in Ruby seems very intuitive to me. The additional functionality (else and retry) could also be very useful in certain scenarios.

If you want to play around with my example you can find it here. Happy coding.