Ruby error message

So you’ve decided to learn how to code. The first thing you need to know about this road you’ve started down is that programming is awesome. Let me repeat that, just to make sure you heard me. Programming is really, really awesome. You may have already built a program that outputs “Hello, World!” to your terminal. If so, you’ve experienced feelings of joy at seeing a program you wrote yourself work properly. Know that that feeling pales in comparison to the feeling you’ll have when you build your first complex application from empty file to finished product. If your experience is like mine, that will be the moment you fall hopelessly in love with code.

But before I let my romanticism lead me off topic, there’s something else you should know about programming. It’s hard. Let me repeat that, just to make sure you heard me. Programming is really, really hard. One of the hardest things about it, I think, especially for the total beginner, is errors. You’ll see error messages way more often than you’ll see your code actually working, so learning to read and understand them is an essential skill that you have to develop. I struggled to understand error messages for the first several months of my programming journey. But when someone finally taught me how to read them, it completely changed my world. Debugging was so much easier (and more fun), and I started to become less frustrated. So I’m writing this for you, dear code newbie, because I wish someone had written something like this for me when I started. We’re going to talk about what errors are, the five most common errors you’ll encounter, what the errors mean, and how to resolve them. I won’t be able to tell you how to deal with every situation in which you might see these errors, but I’ll try and give you a basic framework to work with.

Quick aside: please bear with me if my examples seem a bit contrived. I’m using simple scenarios to explain error messages, even though the code might be unrealistic.

WHAT ARE ERRORS?

Ruby will throw, or raise, an error when something in your program is not working properly. Error messages are your interpreter telling you that something needs to be fixed. If you don’t know what I mean by «interpreter», don’t worry so much about it now. It’s beyond the scope of this post, but just understand that it has to do with how your code is read and executed in your computer. (If you’re dying to know more, Google around, but finish reading this first).

Write this down on a Post-it and stick it next to your computer: errors are not setbacks, they’re opportunities. When your program throws an error, it doesn’t mean that you’re a bad programmer. I think that many of us in the beginning stages feel that if we were better at programming we could build an application and see minimal errors. Thinking this way will only lead to misery, so the first thing you need to realize is that errors are normal. Your program won’t be transmitted from your brain to your text editor in flawless form with awe-inspiring functionality. It will start broken, and require you to fix it. This is the fun part about programming, believe it or not. This is where you get to solve problems and gain the satisfaction that comes from that. And that’s what errors are there for. Errors are your friend, not your foe. Listen to them. They want to help you. Frustration is normal, but always remember that running into errors does not mean you’re a bad programmer. Instead, read on, and learn how to use them to your advantage.

HOW DO I READ AN ERROR MESSAGE?

Error messages give you three key pieces of information, the “where”, the “why”, and the “what”.

A typical error message looks like this:

  
lib/my_file.rb:32::undefined local variable or method `some_variable' for main:Object (NameError)
  

lib/my_file.rb:32 tells you that the error occurred in the lib directory, in the file my_file.rb, on line 32 of that file. That’s the «where».

undefined local variable or method `some_variable' tells you what went wrong. In this case, that Ruby found a local variable or method it didn’t recognize, and it needs to be defined. That’s the «why».

(NameError) tells you the type of exception Ruby raised. In this case, a NameError. You got it, that’s the «what».

The most important piece of advice I can give you is to always read the whole error. When you’re debugging, you’re a detective and you need all the clues you can find. First, find out where the error occurred, and go to that line. Read that line of code, and all the lines immediately preceding and following it. Are there any other methods that call the one where the error occurred? Read those too. Once you do that, you can read the rest of the error message, and find out why the error was thrown, and what error it is. Suddenly you are no longer blindly trying to debug your code, but you have some perspective. You have information that you can use to figure out exactly what went wrong.

Let’s start with this one, and talk about a few other common errors you’ll encounter.

NameError

What the what?

Generally, this error is raised when you call a variable or method that Ruby doesn’t recognize.

How do I fix it?

The first question to ask yourself is, did you define the method or variable in question? I can’t tell you how many times I’ve tried to call a variable that I forgot to define. Check your spelling. Sometimes the problem is as simple as a spelling error in the variable or method you’re trying to call. Or did you assign something to a variable called «user_input», but mistakenly call it «input» in your method? Have you actually built the method you’re trying to call? If that all checks out, then you need to think about scope (if you have no idea what I mean by scope, click here). Did you assign a local variable in one method and try to call it in another?

SyntaxError

 
32: syntax error, unexpected end-of-input, expecting keyword_end
 

What the what?

By far the most common error I encounter every day is the syntax error. You’ll see this bad boy pop up when there is something amiss with the structure of your code. For instance, if you forget an end somewhere.

How do I fix it?

Do what the error says. Fixing this one is as simple as adding an end where it says it needs one. Except when it’s not. Sometimes the error message will say you need a closing end but the source of your trouble is actually several lines above. Start at the top of your code and follow it down, making sure that everything is syntactically correct. Did you iterate over something (do) and forget to close it with an end? Are all your if, elsif, and else statements being used properly? One thing that will help you immensely is to learn to indent your code properly as you write it. Keep your code as organized and clean as you can. It will make it much easier to catch your syntax mistakes along the way.

NoMethodError

What the what?

Closely related to the NameError is the NoMethodError. This means that you are trying to call a method on an object that doesn’t know how to do what you’re asking it to do. If you try and do math with a number that’s a string and not an integer, for instance, or if you created a variable with a nil value, and then forgot to assign another value to it.

Imagine a scenario in which you want to manipulate a range of numbers. You’re not sure how to begin, so you start with something like this:

 
def split_numbers 
  1..10.split
end
 

If you try running this code to see what it returns, you would see:

 
errors.rb:2:in `split_numbers': undefined method `split' for 10:Integer (NoMethodError)
 

How do I fix it?

Google around and make sure you’re using the right method for your object. In the example above, calling .split won’t work because you can’t call it on an integer, even if you’re dealing with a range of integers. It’s a method that operates on strings. Take a close look at your code, as well. It might not be so much that you’re using the wrong method, but maybe you’re using it in the wrong way.

ArgumentError

What the what?

Say we have the following method:

 
def upcase_this_string(string)
  puts string.upcase
end
 

If we call upcase_this_string("I love Ruby"), it will output «I LOVE RUBY». But if we call upcase_this_string("I love Ruby", "a lot"), we’ll see this:

 
1:in `upcase_this_string': wrong number of arguments (given 2, expected 1) (ArgumentError)
 

What this is telling you is that you gave two arguments in your method call, but your method was written to only take one argument.

How do I fix it?

There are a few scenarios that will cause Ruby to throw an ArgumentError, so make sure the number of arguments are correct, and that the datatype you are trying to use is valid.

TypeError

What the what?

This particular error had me confused for a long time, and I’m sure I’m not alone, so let’s dig in. Let’s say you’re doing some super simple arithmetic:

 
def add_one_plus_one
  puts 1+1
end
 

Calling add_one_plus_one and running this file will output 2 to your terminal. but what if instead of puts 1+1, you had for some reason written puts "one"+1? You would see:

 
errors.rb:2:in `+': no implicit conversion of Integer into String (TypeError)
 

How do I fix it?

Basically, all Ruby is telling you here is that when you tried to call +1, it expected the value behind the + sign to be an integer as well. Instead, you tried to call +1 on a string. Ruby encountered an object that wasn’t the type of object it expected it to be. So make sure that for whatever operation you are trying to perform, you are using the proper type of object. For this example, it would have to be either 1+1 which would output 2, or "one"+"one", which would result in "oneone".

FUN-FACT

You’ve probably heard that Ruby is a pure object-oriented language, and that everything in Ruby is an object. Would it blow your mind if I pointed out that this holds true for your errors as well? Errors are objects, instances of the Exception class. If you don’t find this cool yet, just wait. Object-orientation is awesome. Suspend disbelief until you get there, and you’ll see what I mean.

RESOURCES

For more information on the Exception class, and Ruby errors, see the Ruby docs

If I’ve done my job, error messages now seem more understandable, less intimidating, and you now have some idea how to resolve them. If you found this post helpful, please share it with anybody else who might benefit from it. I am always eager to learn and improve, so I would love to hear what people think of this.
If you feel so inclined, follow me on Twitter. I always love to meet new people in the programming community.

Happy coding!

What is exception handling?

Software systems can be quite prone to error conditions. Systems that involve user interaction are more vulnerable to exceptions as they attract errors at multiple fronts. Errors can take many forms — syntactical errors, network errors, form input errors, invalid authentication errors etc. If not accounted for, these can affect user experience and can even manifest as security loopholes, enabling attackers to compromise the system.

Exception handling is used to prevent system failures and to save the user from lousy error messages.

In most cases, when an error condition occurs, the programming language forces the program to terminate and therefore program control is lost. Exception handling allows you (or the program) to not lose control and to be able to deal with what happens after the error has occurred. This gives you some room to make amends — to show affable error messages, to release some resources or to conveniently redirect the user to a relevant page. 

Exception handling helps you clear up the mess, without making it look like one.

It is the process of accommodating error conditions and responding to them programmatically, resulting in execution of a presumably alternate, but already planned sequence of code.

Exception handling in Ruby

In the vast majority of languages, exception handling is performed using “try, throw and catch” mechanisms. When the try block is encountered, the compiler becomes super aware in the lookout for an exception (thrown either manually, or by the language itself) and instructs the catch block to deal with it. Ruby, however decided to go with different names for their conventional exception handling system. 

I find the Ruby terminology for dealing with exceptions a lot more poetic. 

There is a beginning, followed by errors raised and eventually rescued. And like all good things, it comes to an end, unless you want to retry.

begin
    # raise exception here

rescue
    # raised exception handled here

retry
    # retrying the code in the begin block


ensure
    # Always executed

end

Exception handling in Ruby primarily consists of —

• Begin — end block

• Raise

• Rescue

• Retry

• Ensure

Begin — end block, raise, rescue and ensure are analogous to the programming concepts of try, throw, catch and finally. Let’s try to understand them.

Note: Ruby also provides throw and catch functions for handling exceptions, which are lightweight counterparts of raise and rescue that do not build stack traces of the exceptions. Even though raise and rescue based mechanisms are more prevalent among Ruby developers, we’ll see how Ruby’s throw and catch mechanisms can help later in this post.

2.1 Begin — end block

The error prone part of your code comes in the begin block. The corresponding exception handling, through the raise and rescue mechanisms, also happens inside the begin block.

You can use begin blocks to sectionalize the different types of errors that are likely to show up. Differently erroneous codes can be put into different begin — end blocks and can accordingly be handled.

begin
    # code likely to give error comes in this block
    # raising and rescuing something
end

begin
    # raising and rescuing something else
end

Note: The body of a Ruby method can also act as begin-end block and thus does not require an explicit ‘begin’ call.

def raise_and_rescue
  # begin call not necessary 
  # raising and rescuing
end  

2.2 Raise

An exception can either be raised manually by the developer, using the raise command, or automatically by the language itself. Exceptions are raised automatically on incurring a syntactical error, like a variable not declared, a function not defined or an invalid math operation etc.

Based on your application, custom exception conditions can be catered to by manually raising errors. 

A very common use case would be a signup webpage that doesn’t submit the form until you have entered (and/or re-entered) a valid password. This sort of client-side proofing can save you from an unnecessary HTTP request to your server which might either affect database integrity or respond with an error message, which will need to be handled later. 

Let’s see how we can raise an exception in Ruby — 

begin  
    # if some condition is met or not met ->   
    raise "I am the error message!"
    # below lines are not executed    
end  

Here we are just raising an exception, not handling it (yet). This results in the program being terminated where the exception is raised, and as a result, the lines below are not executed. A language-generated error message is output as shown below — 

To prevent this, we can handle the exceptions in our own way, by using rescue blocks.

2.3 Rescue to the rescue

Rescue blocks are like catch blocks that take control of the program after an exception has been raised. Raised exceptions can be followed by one or more rescue blocks to handle the exceptions based on their type. A generic rescue call looks like this — 

begin
    # if some condition is met or not met ->
    raise 'I am the error message!'

    puts 'I am not executed.'
rescue    
    puts 'Rescue to the rescue!'
end    

puts 'Amicably exiting ..'  

Once the exception is handled, execution resumes from after the begin block.

The rescue call defaults to a StandardError parameter. Rescue calls can however be made to handle specific exceptions. Some common Ruby errors (also common across other languages) are — 

• IndexError
• NameError
• RangeError
• TypeError
• ZeroDivisionError
• RuntimeError

Rescue blocks can be made to cater to certain types (classes) of exceptions.

In this way, raised exceptions can be followed by multiple rescue clauses, each responsible for handling a different type of exception. Let’s see how we can do this in code — 

begin  
  # error raised here 
rescue IndexError  
  # dealing in one way
rescue RangeError  
  # dealing in another way  
end 

Arguments can be used with the rescue clause to act as placeholders for the rescued exception — 

begin  
    raise 'I am the error message!'  
rescue StandardError => e  
    # inspecting the raised exception
    puts e.message

    # information about where the exception was raised  
    puts e.backtrace.inspect  
end 

The output tells how the exception was raised in line 2 of our code.

Specific types (classes) of exceptions can be raised even with custom error messages. For example —

begin
raise ZeroDivisionError, "Custom error message"
rescue ZeroDivisionError => e  
    # inspecting the raised exception
    puts e.message  
    puts e.backtrace.inspect
end 

2.4 Else

Sometimes it’s possible that there was nothing to rescue from, that no exception was raised. The else clause can be used in this case as such — 

begin  
rescue StandardError => e  
    # inspecting the raised exception
    puts e.message  
    puts e.backtrace.inspect
else
    puts 'No exception to capture?'
end 

Magic variables

When exceptions are raised, Ruby assigns two variables — $! and $@ with information about the raised exception.

• $! stores the exception message
• $@ stores the backtrace

begin
raise ZeroDivisionError, "Custom error message"
rescue ZeroDivisionError => e
    # inspecting the raised exception
    puts $! # equivalent to e.message
    puts $@ # equivalent to e.backtrace.inspect
end 

2.5 Retry

Well, what if you don’t want to give up? You might want to keep trying till it works. 

This could be a common case when network connections are inconsistent. 

As I type this post on a Google document, at my home, on a poor internet connection, I can see the webpage continuously trying to keep me connected to the internet.

Till now we have seen how rescue blocks can be used to deal with what happens after an exception has occurred. The retry clause allows us to run the begin block again. This can come in handy after we have fixed what caused the exception to happen in the first place. 

Let’s see how retry can help, with a rather simple example. 

We know division of a number by zero is undefined. In the example below, we try to divide a by b (a / b). Initially the denominator, b is zero and therefore the division would raise a ZeroDivisionError. In the rescue block, we change the denominator to 1 and retry the whole thing.

a = 10
b = 0
begin
puts a/b
rescue ZeroDivisionError => e  
    # inspecting the raised exception
    puts e.message  
    puts e.backtrace.inspect
    b = 1
    retry
else
    puts 'No exception to capture?'
    puts 'Division was successful!'
end 

2.6 Ensure

Ensure is like the finally block that we have in other programming languages. It is there to always run at the end of each begin block. Regardless of any control sequence that the program ends up following, the ensure block is always executed at the end of it’s parent begin block. 

begin
    # if some condition is met or not met ->
    raise 'I am the error message!'
rescue    
    puts 'Rescue to the rescue!'
ensure
    puts 'Always executed at the end.'
end    

Ensure blocks are executed even if there isn’t a rescue block to handle a thrown exception. 

begin
    # if some condition is met or not met ->
    puts 'Begin!'
    raise 'I am the error message!'
ensure
    puts 'Executed even when there is no rescue clause'
end 

Note how in this case, even though the ensure block is executed at the end, the raised exception manifests as a runtime error after the ensure block.

Ensure blocks are generally used to free up any resources after an exception has been raised eg. closing database connections, closing file handlers etc. Without such blocks, the program abruptly terminates without clearing the resources.

Throw and catch in Ruby — lightweight alternatives

It’s not a good idea to exceptionally over-handle your code. Extensive raising and rescuing can take a toll on the system’s performance. 

Each time an exception is raised, a stack trace is built that helps in debugging the error. Too many of such handled exceptions can soon become a terrible bottleneck.

Turns out there is a lightweight alternative to the conventional approach that allows you to smoothly transfer program control out of complex nested blocks. Throw clauses and catch blocks in Ruby are linked through a common label name that both share.

throw :labelname
# ..
catch :labelname do
# ..
end

You can also use conditional throw calls as such — 

throw :labelname if a > b
# ..
catch :labelname do
# ..
end

Throw and catch in Ruby are quite different from conventional throw-catch mechanisms in other languages. In Ruby, they are used more for terminating execution quickly, and not as much for handling exceptions. 

It can come in handy when you are working with nested for loops and you want to get out of the computationally expensive mess when a condition is met, without having to use multiple break statements. Throw helps program control to move around swiftly to help programs execute faster, in a more efficient manner, compared to slow conventional begin/raise/rescue mechanisms that are more concerned about the raised exception, where it happened etc.

The way that throw and catch are used is that throw calls are made from inside catch blocks, transferring control from deep inside a nested construct, back to the level of the catch block in the code.

catch(:get_me_out) do
  # arbitrary nested for loop
  for a in 1..5 do
    for b in 1..5 do
      # arbitrary condition
      if a + b == 7
        # throwing to get out of the nested loops
        throw(:get_me_out)
      end
    end
  end
end

puts 'Good to go!'

A throw function can also be called with a custom message as an argument, which the catch block ends up returning after something is thrown.

thrown_msg = catch(:get_me_out) do

  # arbitrary nested for loop
  for a in 1..5 do
    for b in 1..5 do

      # arbitrary condition
      if a + b == 7

        # throwing to get out of the nested loops
        throw(:get_me_out, 'Inside this mess, get me out')
      end
    end
  end
end

puts thrown_msg
puts 'Good to go!'

Custom Exception class in Ruby

We can create our own Exception classes that cater to specific requirements in our projects. This can be done by inheriting from the provided StandardError class.

class MyCustomError < StandardError
end

raise MyCustomError

It’s good to have an error message to accompany the raised exception. We can do this by overriding the initialize method for our custom class with a default msg argument.

class MyCustomError < StandardError
  def initialize(msg="Custom error message")
    # to override the method
    super
  end
end

raise MyCustomError

Wrapping it up

In this post, we looked at —

• What is exception handling (in general)
• Exception handling in Ruby —
• Begin — end block
• Raise
• Rescue
• Else
• Retry
• Ensure
• Throw and catch in Ruby
• Custom exception classes

All in all, we learnt how Ruby prefers a different terminology for dealing with exceptions. Except for the retry function, the begin / raise / rescue paradigm resonates with the conventional try / throw / catch setup used across most other programming languages. Throw and catch in Ruby however help in quickly getting yourself out of complex constructs. We also saw how we can create our application-specific custom Exception classes that inherit from the StandardError class.

Try ScoutAPM

Thanks for reading our blog. Now that you have a handle on handling exceptions, you need the best way to find them in your application.  Sign up here today for a free trial or contact us with any queries you might have.   Want to show off Scout to your fellow developers? Click here for some free ScoutAPM swag.

The execution and the exception always go together. If you are opening a file, which does not exist, then if you did not handle this situation properly, then your program is considered to be of bad quality.

The program stops if an exception occurs. So exceptions are used to handle various type of errors, which may occur during a program execution and take appropriate action instead of halting program completely.

Ruby provide a nice mechanism to handle exceptions. We enclose the code that could raise an exception in a begin/end block and use rescue clauses to tell Ruby the types of exceptions we want to handle.

Syntax

begin  
# -  
rescue OneTypeOfException  
# -  
rescue AnotherTypeOfException  
# -  
else  
# Other exceptions
ensure
# Always will be executed
end

Everything from begin to rescue is protected. If an exception occurs during the execution of this block of code, control is passed to the block between rescue and end.

For each rescue clause in the begin block, Ruby compares the raised Exception against each of the parameters in turn. The match will succeed if the exception named in the rescue clause is the same as the type of the currently thrown exception, or is a superclass of that exception.

In an event that an exception does not match any of the error types specified, we are allowed to use an else clause after all the rescue clauses.

Example

#!/usr/bin/ruby

begin
   file = open("/unexistant_file")
   if file
      puts "File opened successfully"
   end
rescue
      file = STDIN
end
print file, "==", STDIN, "n"

This will produce the following result. You can see that STDIN is substituted to file because open failed.

#<IO:0xb7d16f84>==#<IO:0xb7d16f84>

Using retry Statement

You can capture an exception using rescue block and then use retry statement to execute begin block from the beginning.

Syntax

begin
   # Exceptions raised by this code will 
   # be caught by the following rescue clause
rescue
   # This block will capture all types of exceptions
   retry  # This will move control to the beginning of begin
end

Example

#!/usr/bin/ruby

begin
   file = open("/unexistant_file")
   if file
      puts "File opened successfully"
   end
rescue
   fname = "existant_file"
   retry
end

The following is the flow of the process −

• An exception occurred at open.
• Went to rescue. fname was re-assigned.
• By retry went to the beginning of the begin.
• This time file opens successfully.
• Continued the essential process.

NOTE − Notice that if the file of re-substituted name does not exist this example code retries infinitely. Be careful if you use retry for an exception process.

Using raise Statement

You can use raise statement to raise an exception. The following method raises an exception whenever it’s called. It’s second message will be printed.

Syntax

raise 

OR

raise "Error Message" 

OR

raise ExceptionType, "Error Message"

OR

raise ExceptionType, "Error Message" condition

The first form simply re-raises the current exception (or a RuntimeError if there is no current exception). This is used in exception handlers that need to intercept an exception before passing it on.

The second form creates a new RuntimeError exception, setting its message to the given string. This exception is then raised up the call stack.

The third form uses the first argument to create an exception and then sets the associated message to the second argument.

The fourth form is similar to the third form but you can add any conditional statement like unless to raise an exception.

Example

#!/usr/bin/ruby

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.'  

This will produce the following result −

I am before the raise.  
I am rescued.  
I am after the begin block.  

One more example showing the usage of raise −

#!/usr/bin/ruby

begin  
   raise 'A test exception.'  
rescue Exception => e  
   puts e.message  
   puts e.backtrace.inspect  
end  

This will produce the following result −

A test exception.
["main.rb:4"]

Using ensure Statement

Sometimes, you need to guarantee that some processing is done at the end of a block of code, regardless of whether an exception was raised. For example, you may have a file open on entry to the block and you need to make sure it gets closed as the block exits.

The ensure clause does just this. ensure goes after the last rescue clause and contains a chunk of code that will always be executed as the block terminates. It doesn’t matter if the block exits normally, if it raises and rescues an exception, or if it is terminated by an uncaught exception, the ensure block will get run.

Syntax

begin 
   #.. process 
   #..raise exception
rescue 
   #.. handle error 
ensure 
   #.. finally ensure execution
   #.. This will always execute.
end

Example

begin
   raise 'A test exception.'
rescue Exception => e
   puts e.message
   puts e.backtrace.inspect
ensure
   puts "Ensuring execution"
end

This will produce the following result −

A test exception.
["main.rb:4"]
Ensuring execution

Using else Statement

If the else clause is present, it goes after the rescue clauses and before any ensure.

The body of an else clause is executed only if no exceptions are raised by the main body of code.

Syntax

begin 
   #.. process 
   #..raise exception
rescue 
   # .. handle error
else
   #.. executes if there is no exception
ensure 
   #.. finally ensure execution
   #.. This will always execute.
end

Example

begin
   # raise 'A test exception.'
   puts "I'm not raising exception"
rescue Exception => e
   puts e.message
   puts e.backtrace.inspect
else
   puts "Congratulations-- no errors!"
ensure
   puts "Ensuring execution"
end

This will produce the following result −

I'm not raising exception
Congratulations-- no errors!
Ensuring execution

Raised error message can be captured using $! variable.

Catch and Throw

While the exception mechanism of raise and rescue is great for abandoning the execution when things go wrong, it’s sometimes nice to be able to jump out of some deeply nested construct during normal processing. This is where catch and throw come in handy.

The catch defines a block that is labeled with the given name (which may be a Symbol or a String). The block is executed normally until a throw is encountered.

Syntax

throw :lablename
#.. this will not be executed
catch :lablename do
#.. matching catch will be executed after a throw is encountered.
end

OR

throw :lablename condition
#.. this will not be executed
catch :lablename do
#.. matching catch will be executed after a throw is encountered.
end

Example

The following example uses a throw to terminate interaction with the user if ‘!’ is typed in response to any prompt.

def promptAndGet(prompt)
   print prompt
   res = readline.chomp
   throw :quitRequested if res == "!"
   return res
end

catch :quitRequested do
   name = promptAndGet("Name: ")
   age = promptAndGet("Age: ")
   sex = promptAndGet("Sex: ")
   # ..
   # process information
end
promptAndGet("Name:")

You should try the above program on your machine because it needs manual interaction. This will produce the following result −

Name: Ruby on Rails
Age: 3
Sex: !
Name:Just Ruby

Class Exception

Ruby’s standard classes and modules raise exceptions. All the exception classes form a hierarchy, with the class Exception at the top. The next level contains seven different types −

• Interrupt
• NoMemoryError
• SignalException
• ScriptError
• StandardError
• SystemExit

There is one other exception at this level, Fatal, but the Ruby interpreter only uses this internally.

Both ScriptError and StandardError have a number of subclasses, but we do not need to go into the details here. The important thing is that if we create our own exception classes, they need to be subclasses of either class Exception or one of its descendants.

Let’s look at an example −

class FileSaveError < StandardError
   attr_reader :reason
   def initialize(reason)
      @reason = reason
   end
end

Now, look at the following example, which will use this exception −

File.open(path, "w") do |file|
begin
   # Write out the data ...
rescue
   # Something went wrong!
   raise FileSaveError.new($!)
end
end

The important line here is raise FileSaveError.new($!). We call raise to signal that an exception has occurred, passing it a new instance of FileSaveError, with the reason being that specific exception caused the writing of the data to fail.