Don’t confuse Ruby’s ‘throw’ statement with ‘raise’

Programmers who come to Ruby from other languages — particularly C++, C♯ or Java — tend to misuse Ruby’s throw statement. They type throw when they mean to type raise.

What’s the difference?

Like C++, C♯ and Java, Ruby has first-class support for exceptions. Exceptions can be thrown using the raise statement and caught using the rescue keyword. Rubyists often speak of “errors” rather than “exceptions.” This is because it’s accepted that the names of Ruby exception classes generally end in Error rather than Exception, excepting the base class for exceptions which is called Exception. (Still with me?)

You may say, “Okay, so I’ll start saying ‘error’ when I mean ‘exception.’ But why can’t I at least type the throw and catch keywords I’m used to typing?”

Ruby has a distinctive language feature that consists of pairs of throw and catch statements. The throw-catch paradigm works similarly to raise and rescue. When Ruby encounters a throw statement, like a good matchmaker, she walks back up the execution stack (“catch me a catch!”) looking for a suitable catch. Here’s some code to illustrate.

class Tevye

  def live

  def rich_man?


  def method_missing(method, *args)

  def toil_in_anatevka
    if self.rich_man?
      throw :miracle_of_miracles,
            'Emigrated to the Cayman Islands'


poor_tevye =
result = catch(:miracle_of_miracles) do

What is inevitable result of toiling in Anatevka? Nothing too surprising: it is being a :pauper.

But let’s change Tevye’s fortunes a bit and reward him richly for his labor. Take a look.

rich_tevye =
def rich_tevye.rich_man?
result = catch(:miracle_of_miracles) do

What comes of Tevye’s hard work if deus ex machina descends upon the village? Tevye gets to retire to the western Caribbean, and his wife, Golde, grows a proper double chin.

Just as an unrescued error causes the Ruby process to crash, so a throw without a matching catch will raise an error (which in turn you can rescue).

It’s not just semantics

You cannot simply throw and catch wherever you would otherwise raise and rescue. There are differences beyond that the latter is for representing exception conditions and the former for other kinds of stack popping.

To begin with, (as you would expect from your experiences with other languages) rescue NameError rescues errors of type NameError as well as subclasses such as NoMethodError. By analogy you might presume that catch Entertainer would handle all these throw statements:

• throw Entertainer • throw • throw BroadwayStar • throw

You would be wrong: catch Entertainer handles only throw Entertainer.

Another important difference is that throw can take two arguments, as demonstrated in the Tevye class above. The second argument to throw is what Ruby returns from the matching catch statement (also demonstrated above).

A further distinction is the fact that rescue can appear more than once in a begin-end or def-end pair. The first matching rescue in a sequence wins.

rescue AParticularKindOfError
  # Insert heroism here.
rescue Exception

By contrast, catch is a block construct. Multiple catch statements must be nested in order to appear together.

catch :foo do
  catch :bar do

Prior to Ruby v1.9, only symbols (for example, :pauper) could be thrown and caught. This restriction was removed, so now you can throw any Ruby object and catch it successfully.

The bottom line

When should you use this language feature? Not very often. As you probably noticed, my contrived example about peasant life in Tsarist Russia is a questionable application of the throw-catch pattern. There are two plausible examples in the Pickaxe book ( Fundamentally, throw-catch is a way to escape from the bowels of multiple layers of control flow without abusing raise-rescue for this purpose.

But if you have so many layers of flow control that you’re tempted to throw in order to get out of them quickly, consider trying to eliminate the layers first.

How to Make Your HTML Website Faster

1. Split Content

The chief purpose of responsive web design is to enhance web browsing experience on mobile devices without compromising on main contents of a website. But research findings reveal that around 80% people aren’t satisfied with mobile browsing experience, and slow performance of websites is a major reason of this disappointment. Clearly, responsive sites are facing performance issues which is chiefly because of too many HTML elements, excess loading time and extra content.

For seamless mobile browsing experience, it is very important to optimize websites so that their performance is accelerated. This is even more important for businesses because slow websites can have negative impact on marketing and promotion. Here are four actionable tips that will make responsive sites faster.

How to Make Your HTML Website Faster

A desktop website can afford to have many contents in a single webpage. But when responsive designing is used in it, then it is better to split its contents in separate web pages. This reduces HTML’s payload and avoids downloading of any associated dependencies. For example, when any product page of an ecommerce site is viewed on smaller screens, then the main product page should contain only generic information.

Keep separate web pages for ‘customer reviews’ and ‘new offers’ but, provide links for these pages within the main product page. Here, a single product page (for desktop website) splits into three different pages (when it becomes responsive). This will reduce HTTP requests as well as HTML size and will increase the site’s speed.

2. Optimize Images

High resolution images are great for desktop websites, but they are responsible for slowing down the performance of a responsive site. Images take the largest amount of KBs which is why websites with too many images tend to underperform on a mobile browser. Using CSS3 styling features like rounded corners and gradients fills will cut down HTTP requests and increase a site’s speed.

However, for images, one of the best techniques is using Adaptive Images. This software detects the screen size of a visitor’s device, and it automatically creates, caches and delivers an appropriate re-scaled version of embedded HTML images. There’s no need for mark-up changes.

3. Reduce JavaScript

JavaScript has significant effect on page speed. If your page has complex scripts, then mobile visitors of your website may have to spend few seconds in staring at blank page. This is because JavaScript increases a site’s loading time on tablet or smartphone. So reducing JavaScript can help your responsive site to perform better.

As a web designer, you must rethink using JavaScript and try to use it only when absolutely necessary. The best results can be achieved by placing scripts at the bottom of HTML. This prevents unnecessary blocking. However, if a script is absolutely necessary, then keep it inline and keep it small.

4. Use Conditional Loading

This is a very important and popular technique to enhance performance of responsive sites. Conditional loading prevents users to download site contents that make it slow. It can stop different kinds of content from downloading like maps, widgets and images. While implementing conditional loading, designers or developers should thoroughly test the site.

This should be done during optimization stages because it is easier to pick out flaws during that time. Further, it is easier to make corrections during optimization rather than doing so at the very end.

enter image description here

The Bottomline

Mobile users expect the same speed response while mobile browsing that they find in desktops and this expectation can be met only when responsive sites take minimum time to load. The above mentioned techniques can enhance speed of responsive sites by eliminating unnecessary contents and scripts. However, web designers must try to incorporate speed enhancing techniques during the build process of a website, and not as an afterthought.