Simone Carletti's Blog » exceptions

How slow are (Ruby) Exceptions?

Simone Carletti — Wed, 13 Jan 2010 08:01:58 +0000

If you are used to benchmark your Ruby scripts or if you ever had to improve the performance of some strategic tasks, then this post won’t tell you nothing new because you should already know that Exceptions are slow. And this is not really a Ruby problem: .NET Exceptions are slow, JAVA Exceptions are slow just because the begin/raise/rescue (or try/throw/catch) architecture is slow by nature.

But how slow are Ruby Exceptions?

The answer to this question really depends on how complex is your code. Here I just want to show you a very simple example, extracted from a really strategic RoboDomain DNS sorting algorithm.

The code is fairly simple: the value for an A record is expected to be an IP Address while the value for a NS record is expected to be represented by a FQDN as string. The code should parse the data and return the normalized value depending on some conditions.

The first version of the algorithm is completely based on Exceptions. IPAddr raises an ArgumentError when the argument is not a valid IP Address. In this case, the script gracefully returns the value as string.

The second version checks against the record value (I agree with you that is quite empiric, but representative for the sake of this benchmark).

The third version is a less empiric alternative that uses some regular expressions to check whether the data looks like an IP before actually feeding the IPAddr class. Under the hood, the IPAddr class performs a really similar task, the only difference here is that in the latter case I’m not using Exceptions at all.

Results speak for themselves. *

(*) As pointed out by Curtis Summers in the comments,a huge amount of time is actually spent by IPAddr trying to resolve the hostname. For more benchmarks, also look at this test.

With Ruby 1.8.7, the algorithm (note, this is a super-simplified version of the original algorithm) is about 37 times slower when Exceptions are involved.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

$ ruby if_vs_exception.rb
Rehearsal ------------------------------------------------
NS exception 4.330000 5.750000 10.080000 ( 37.599575)
NS if 0.140000 0.010000 0.150000 ( 0.136280)
NS regexp 0.450000 0.000000 0.450000 ( 0.454040)
A exception 2.010000 0.020000 2.030000 ( 2.047711)
A if 2.060000 0.020000 2.080000 ( 2.074642)
A regepx 2.030000 0.020000 2.050000 ( 2.054930)
-------------------------------------- total: 16.840000sec

user system total real
NS exception 4.420000 5.810000 10.230000 ( 38.350608)
NS if 0.130000 0.000000 0.130000 ( 0.130863)
NS regexp 0.450000 0.000000 0.450000 ( 0.447975)
A exception 2.000000 0.020000 2.020000 ( 2.016231)
A if 2.020000 0.020000 2.040000 ( 2.043085)
A regepx 2.030000 0.020000 2.050000 ( 2.048402)

The same story with Ruby 1.9.1.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Rehearsal ------------------------------------------------
NS exception 4.650000 5.800000 10.450000 ( 39.134858)
NS if 0.080000 0.000000 0.080000 ( 0.079427)
NS regexp 0.320000 0.000000 0.320000 ( 0.320389)
A exception 1.180000 0.010000 1.190000 ( 1.182892)
A if 1.200000 0.000000 1.200000 ( 1.209433)
A regepx 1.220000 0.000000 1.220000 ( 1.219345)
-------------------------------------- total: 14.460000sec

user system total real
NS exception 4.520000 5.720000 10.240000 ( 37.931455)
NS if 0.080000 0.000000 0.080000 ( 0.078286)
NS regexp 0.320000 0.000000 0.320000 ( 0.320988)
A exception 1.190000 0.000000 1.190000 ( 1.186198)
A if 1.210000 0.010000 1.220000 ( 1.220254)
A regepx 1.220000 0.000000 1.220000 ( 1.215634)

Does this mean I should forget about Exceptions?

Absolutely no! I love Exceptions and you should love them too. However, Exceptions should not be expected and, in some circumstances, an if can be much more convenient, or at least, efficient.

One important lesson to learn from these benchmarks is that exceptions should not be part of the regular application flow. This shouldn’t prevent you to use them to handle unexpected situations and exception performance shouldn’t be a big deal in this case.

A lesson learned from this specific case, is to avoid using exceptions in place of conditional statements to handle not exceptional situations.

UPDATE: for more interesting comments, check out the Reddit page.

Understanding Ruby and Rails: Rescuable and rescue_from

Simone Carletti — Mon, 21 Dec 2009 08:00:34 +0000

This article targets Rails 2.3 and Rails 3. The information contained in this page might not apply to different versions.

This is article is part of my series Understanding Ruby and Rails. Please see the table of contents for the series to view the list of all posts.

Last time I talked about the ActiveSupport Module#delegate method. Today, I want to introduce an other poweful ActiveSupport module: Rescuable, also known in the Rails ecosystem as rescue_from.

`rescue_from` and Rails

Starting from the release 2.0, Rails provides a clean way to rescue exceptions in a controller, mapping specific error classes to corresponding handlers.

Let’s see an example. A call to ActiveRecord#find raises an ActiveRecord::RecordNotFound exception when the record passed as parameter doesn’t exist. Assuming you want to display a nice 404 error page, you need to rescue the exception in each action where a find call is performed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

class PostsController < ApplicationController
def show
@post = Post.find(params[:id])
rescue ActiveRecord::RecordNotFound
render_404
end

def edit
@post = Post.find(params[:id])
rescue ActiveRecord::RecordNotFound
render_404
end

def destroy
@post = Post.find(params[:id])
@post.destroy
rescue ActiveRecord::RecordNotFound
render_404
end
end

class UserController < ApplicationController
def show
@user = User.find(params[:id])
rescue ActiveRecord::RecordNotFound
render_404
end

# ...
end

As you can see, this approach leads to lot of code duplication if you count the number of find calls for each action per model. The rescue_from method is exactly the solution we are looking for. Instead of catching the exception at action-level, we instruct the controller to rescue all the ActiveRecord::RecordNotFound errors and forward the exception to the proper handler.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

class ApplicationController < ActionController::Base
rescue_from ActiveRecord::RecordNotFound, :with => :render_404
end

class PostsController < ApplicationController
def show
@post = Post.find(params[:id])
end

def edit
@post = Post.find(params[:id])
end

def destroy
@post = Post.find(params[:id])
@post.destroy
end

end

class UserController < ApplicationController
def show
@user = User.find(params[:id])
end

# ...
end

The rescue_from method also accepts a block or a Proc. And if you need, you can also selectively rescue exceptions according to the error message or other properties.

`rescue_from` and Ruby

The rescue_from was born as a Rails feature but because it’s packaged in the ActiveSupport::Rescuable module, you can easily reuse it elsewhere in your code to take advantage of the same clean and concise exception handling mechanism.

All you have to do is to require ActiveSupport library and include the ActiveSupport::Rescuable module in your class. If you are in a Rails project, ActiveSupport is already loaded. Then, add a rescue block and use the rescue_with_handler method to filter any error raised by the application.

1
2
3
4
5
6
7
8
9

class MyClass
include ActiveSupport::Rescuable

def method
# ...
rescue Exception => exception
rescue_with_handler(exception) || raise
end
end

The following is a simplified example extracted from RoboDomain. The Queue::Jobs::Base is the base class for all DelayedJob jobs. Each child class implements the perform method, as requested by DelayedJob. However, the base class provides an internal method called execute which wraps all executions and rescues from some known errors to prevent DelayedJob to re-schedule the failed task.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

class Queue::Jobs::Base
include ActiveSupport::Rescuable

rescue_from ActiveRecord::RecordNotFound, :with => :known_error

protected

def execute(&block)
yield
rescue Exception => exception
rescue_with_handler(exception) || raise
end

def known_error(exception)
@error = exception
Rails.logger.error "[JOBS] Exception #{exception.class}: #{exception.message}"
end

end

class Queue::Jobs::FetchWhois < Queue::Jobs::Base

rescue_from Hostname::NotLikeDomain, :with => :known_error
# ActiveRecord::RecordNotFound already defined in parent class

def initialize(hostname_id)
@hostname_id = hostname_id
end

def perform
execute do
hostname = Hostname.find(@hostname_id)
end
end

end

As you can see, using the ActiveSupport::Rescuable module I don’t need to clutter my code with multiple begin/rescue/raise statements.

A word of warning

Like any reusable pattern, ActiveSupport::Rescuable is not the ultimate and definitive solution for any piece of code where you need to rescue from an exception. Use it if you actually need it, don’t try to force your code to fit this implementation.

Re-raise a Ruby exception in a Rails rescue_from statement

Simone Carletti — Wed, 04 Nov 2009 19:58:02 +0000

Let’s say you are using rescue_from in your Rails application to rescue some type of exceptions that are thrown in your application. For example, you want to rescue a ActiveRecord::StatementInvalid but not every ActiveRecord::StatementInvalid: just those ActiveRecord::StatementInvalid exceptions where the exception message matches a defined pattern.

In this specific case, the following code won’t work.

1
2
3
4
5
6
7
8
9
10
11
12
13

class ApplicationController < ActionController::Base

# ...

rescue_from ActiveRecord::StatementInvalid, :with => :rescue_invalid_encoding

protected

def rescue_invalid_encoding
# ...
end

end

This is because a ActiveRecord::StatementInvalid is a generic error class and the rescue_from statement will catch any ActiveRecord::StatementInvalid indistinctly. But you don’t want this, so you’ll decide to go ahead and use the old-fashioned if school to filter the exception message.

Only exceptions matching given message pattern should be catched. Any other exception should be released (or to use a technical jargon, rethrown).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class ApplicationController < ActionController::Base

# ...

rescue_from ActiveRecord::StatementInvalid do |exception|
if exception.message =~ /invalid byte sequence for encoding/
rescue_invalid_encoding(exception)
else
raise
end
end

protected

def rescue_invalid_encoding(exception)
head :bad_request
end

end

The way you rethrow an exception in Ruby is calling raise without passing any exception class or message. Ruby will dutifully re-raise the more recent exception.

Unfortunately, the else statement won’t as expected. The exception is correctly rethrown but it isn’t catched by the standard Rails rescue mechanism and the standard exception page is not rendered. Also, the exception is completely invisible to any exception logging platform that relies on rescue_action_in_public such as Hoptoad or Exceptional.

The explanation is simple. To prevent an infinite loop, Rails has a special Failsafe mechanism. When an Exception occurs in the Exception rescue execution, Rails immediately breaks the execution and enter in Failsafe mode.

From the Rails log

1
2
3
4
5

Processing ApplicationController#index (for 127.0.0.1 at 2009-11-03 23:30:19) [GET]
Parameters: {"action"=>"index", "controller"=>"welcome"}
/! FAILSAFE /! Wed Nov 03 23:30:19 +0100 2009
Status: 500 Internal Server Error
ActiveRecord::StatementInvalid

In order to pass invoke the standard rescue mechanism you need to manually call the rescue_action_without_handler(exception) method.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class ApplicationController < ActionController::Base

# ...

rescue_from ActiveRecord::StatementInvalid do |exception|
if exception.message =~ /invalid encoding/
rescue_invalid_encoding(exception)
else
rescue_action_without_handler(exception)
end
end

protected

def rescue_invalid_encoding(exception)
head :bad_request
end

end

A work of warning: This is a Rails internal API so it can change without additional notice in future versions so be sure to create a test suite to prevent problems when upgrading your Rails version.

Here’s an example of integrational test.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

require 'test_helper'

class RescuableTest < ActionController::IntegrationTest

fixtures :all

test "rescue from ActiveRecord::StatementInvalid" do
MainController.any_instance.expects(:set_locale).raises(ActiveRecord::StatementInvalid, 'PGError: ERROR: invalid byte sequence for encoding "UTF8": 0xed706')

get "/"
assert_response 400
end

test "rescue from ActiveRecord::StatementInvalid with re-raise" do
MainController.any_instance.expects(:set_locale).raises(ActiveRecord::StatementInvalid, 'Global error')

get "/"
assert_response 500
# perhaps you might want to check here additional instance variables
# or flash messages
end

end