Handling an Exception

Table of contents:

Credit: Steve Arneil

Problem

You want to handle or recover from a raised exception.

Solution

Rescue the exception with a begin/rescue block. The code you put into the rescue clause should handle the exception and allow the program to continue executing.

This code demonstrates the rescue clause:

	def raise_and_rescue
	 begin
	 puts I am before the raise.
	 raise An error has occurred.
	 puts I am after the raise.
	 rescue
	 puts I am rescued!
	 end
	 puts I am after the begin block.
	end

	raise_and_rescue
	# I am before the raise.
	# I am rescued!
	# I am after the begin block.

The exception doesn stop the program from running to completion, but the code that was interrupted by the exception never gets run. Once the exception is handled, execution continues immediately after the begin block that spawned it.

Discussion

You can handle an exception with a rescue block if you know how to recover from the exception, if you want to display it in a nonstandard way, or if you know that the exception is not really a problem. You can solve the problem, present it to the end user, or just ignore it and forge ahead.

By default, a rescue clause rescues exceptions of class StandardError or its subclasses. Mentioning a specific class in a rescue statement will make it rescue exceptions of that class and its subclasses.

Heres a method, do_it, that calls the Kernel#eval method to run some Ruby code passed to it. If the code cannot be run (because its not valid Ruby), eval raises an exceptiona SyntaxError. This exception is not a subclass of StandardError; its a subclass of ScriptError, which is a subclass of Exception.

	def do_it(code)
	 eval(code)
	rescue
	 puts "Cannot do it!"
	end

	do_it(puts 1 + 1)
	# 2

	do_it(puts 1 +)
	# SyntaxError: (eval):1:in do_it: compile error

That rescue block never gets called because SyntaxError is not a subclass of StandardError. We need to tell our rescue block to rescue us from SyntaxError, or else from one of its superclasses, ScriptError and Exception:

	def do_it(code)
	 eval(code)
	rescue SyntaxError
	 puts "Cannot do it!"
	end

	do_it(puts 1 +)
	# Cannot do it!

You can stack rescue clauses in a begin/rescue block. Exceptions not handled by one rescue clause will trickle down to the next:

	begin
	 # …
	rescue OneTypeOfException
	 # …
	rescue AnotherTypeOfException
	 # …
	end

If you want to interrogate a rescued exception, you can map the Exception object to a variable within the rescue clause. Exception objects have useful methods like message and backtrace:

	begin
	 raise A test exception.
	rescue Exception => e
	 puts e.message
	 puts e.backtrace.inspect
	end
	# ["(irb):33:in irb_binding",
	# "/usr/lib/ruby/1.8/irb/workspace.rb:52:in irb_binding",
	# ":0"]

You can also use the special variable $! within a rescue block to refer to the most recently raised Exception. If you do a require English, you can use the $ERROR_INFO variable, which is easier to remember.

	require English
	begin
	 raise Another test 
exception.
	rescue Exception
	 puts $!.message
	 puts $ERROR_INFO.message
	end
	# Another test exception.
	# Another test exception.

Since $! is a global variable, and might be changed at any time by another thread, its safer to map each Exception object you rescue to an object.

Problem

Solution

Discussion

See Also