Ruby ArgumentError trapping - ruby

Given a class:
class Foo
def initialize(input1)
#input1 = input1
end
end
is there some way that would throw a more helpful error against a = Foo.new()? How can I build a method that throws an ArgumentError in a more helpful way?
I'd like to build this into the class. The Programming Ruby site lists several error-trapping mechanisms, but all of these seem to depend on wrapping a = Foo.new() in a catch block or the like. I would like to have my error trapping within the class itself however.

Since you're new to Ruby it's understandable this error might seem odd, yet it's also an error that's very specific to passing the wrong arguments in. Remapping it to something else isn't necessarily helpful, it ends up hiding problems in your code. I'd suggest leaving it as-is and expecting errors like that to occur if you're not calling it correctly.
The alternative is, at least in newer versions of Ruby, to declare keyword arguments with no defaults:
def initialize(input1:)
end
That's a required keyword argument, and the error is more specific:
ArgumentError: missing keyword: input1
The downside is you have to call it like this:
Foo.new(input1: 'test')
That might be beneficial in terms of clarity. It's up to you.

you can use a default value and raise whatever error you need within the initialize method for example
Class A
def initialize(a = nil)
raise("give me an A") if a.nil?
#a = a
end
end

You can do this pretty simply by raising that error when the argument is not defined. You can add a message to the ArgumentError exception by specifying it as an argument on the exception:
class Foo
def initialize(input1=nil)
raise ArgumentError, "expected a value for Foo.new('value')" unless input1
#input1 = input1
end
end

After reading Programming Ruby a bit more, I think using alias_method as a hook might serve:
alias_method :initialize_orig, :initialize
def initialize(*args)
begin
result = initialize_orig(*args)
return result
rescue Exception
$stderr.print "Need to use argument 'input1'\n"
raise
end
end

Related

Catching exceptions while using an external gem

I have written a program that utilizes an external ruby gem. As I am doing a lot of different actions with this, I want to be able to rescue and handle exceptions across the board, instead of implementing it each time I call a method.
What is the best way to do this?
Should I write my own method that simply calls the external gem and also rescues exceptions? Or is there another way to do something like "Whenever an exception of this type comes up anywhere in the program, handle it this way"?
I know that if I wrote the external gem code I could add error handling like that, but that is not feasible.
The basic answer to this is probably to wrap the class you're working with; Ruby allows for a lot of flexibility for doing this since it has method_missing and a pretty dynamic class environment. Here's an example (which may or may not be fatally flawed, but demonstrates the principle:
# A Foo class that throws a nasty exception somewhere.
class Foo
class SpecialException < Exception; end
def bar
raise SpecialException.new("Barf!")
end
end
# This will rescue all exceptions and optionally call a callback instead
# of raising.
class RescueAllTheThings
def initialize(instance, callback=nil)
#instance = instance
#callback = callback
end
def method_missing(method, *args, &block)
if #instance.respond_to? method
begin
#instance.send(method, *args, &block)
rescue Exception => e
#callback.call(e) if #callback
end
else
super
end
end
end
# A normal non-wrapped Foo. Exceptions will propagate.
raw_foo = Foo.new
# We'll wrap it here with a rescue so that we don't exit when it raises.
begin
raw_foo.bar
rescue Foo::SpecialException
puts "Uncaught exception here! I would've exited without this local rescue!"
end
# Wrap the raw_foo instance with RescueAllTheThings, which will pass through
# all method calls, but will rescue all exceptions and optionally call the
# callback instead. Using lambda{} is a fancy way to create a temporary class
# with a #call method that runs the block of code passed. This code is executed
# in the context *here*, so local variables etc. are usable from wherever the
# lambda is placed.
safe_foo = RescueAllTheThings.new(raw_foo, lambda { |e| puts "Caught an exception: #{e.class}: #{e.message}" })
# No need to rescue anything, it's all handled!
safe_foo.bar
puts "Look ma, I didn't exit!"
Whether it makes sense to use a very generic version of a wrapper class, such as the RescueAllTheThings class above, or something more specific to the thing you're trying to wrap will depend a lot on the context and the specific issues you're looking to solve.

Can I tell a Ruby method to expect a specific parameter type?

def doSomething(value)
if (value.is_a?(Integer))
print value * 2
else
print "Error: Expected integer value"
exit
end
end
Can I tell a Ruby method that a certain parameter should be an Integer, otherwise crash? Like Java.
No, you can't. You can only do what you're already doing: check the type yourself.
I'm late to the party, but I wanted to add something else:
A really important concept in Ruby is Duck Typing. The idea behind this principle is that you don't really care about the types of your variables, as far as they can do what you want to do with them. What you want in your method is to accept a variable that responds to (*). You don't care about the class name as far as the instance can be multiplied.
Because of that, in Ruby you will see more often the method #responds_to? than #is_a?
In general, you will be doing type assertion only when accepting values from external sources, such as user input.
I would suggest a raise unless type match at the beginning of the method
def do_something(value)
raise TypeError, 'do_something expects an integer' unless value.kind_of?(Integer)
...
end
This is raise an error and exit unless value is an Integer
You can raise an Exception anytime arbitrarily if you deem it necessary.
def doSomething(value)
if (value.is_a?(Integer))
print value * 2
else
raise "Expected integer value"
end
end
Whether or not you really want to do this is a separate issue. :)
Ruby doesn't have parameter type verification, though you can add sugar method to all objects for convenience to verify type like this:
def doSomething(value)
print value.should_be(Numeric) * 2
end
or
def initialize(fruit)
#fruit = fruit.should_be(Fruit)
end
Object.class_eval do
def should_be cls
hide_from_stack = true
if self && !self.is_a?(cls)
raise("Expected class #{cls}, got #{self.class}")
end
self
end
end

Equivalent of “pass” in Ruby

In python there is a pass keyword for defining an empty function, condition, loop, ...
Is there something similar for Ruby?
Python Example:
def some_function():
# do nothing
pass
No, there is no such thing in Ruby. If you want an empty block, method, module, class etc., just write an empty block:
def some_method
end
That's it.
In Python, every block is required to contain at least one statement, that's why you need a "fake" no-op statement. Ruby doesn't have statements, it only has expressions, and it is perfectly legal for a block to contain zero expressions.
nil is probably the equivalent of it:
def some_function
nil
end
It's basically helpful when ignoring exceptions using a simple one-line statement:
Process.kill('CONT', pid) rescue nil
Instead of using a block:
begin
Process.kill('CONT')
rescue
end
And dropping nil would cause syntax error:
> throw :x rescue
SyntaxError: (irb):19: syntax error, unexpected end-of-input
from /usr/bin/irb:11:in `<main>'
Notes:
def some_function; end; some_function returns nil.
def a; :b; begin; throw :x; rescue; end; end; a; also returns nil.
You always have end statements, so pass is not needed.
Ruby example:
def some_function()
# do nothing
end
Ruby 3.0
As of Ruby 3.0, so-called "endless" method definitions are now supported -- we no longer require end statements with every single method definition. This means the most concise way of expressing an empty method like the example above is now arguably something like this:
def some_function = nil
Alternatively, there has always been an uglier one-line option using the much-hated semicolon:
def some_function; end
Note that this doesn't really change anything about the first solution except how the code can be written.
Single line functions and classes
def name ; end
class Name ; end
works fine for pseudocode.
As answered before everything in ruby is an expression so it is fine to leave it blank.
def name
end
class Name
end
A ruby alternative for python programmers who love the pass keyword
def pass
end
# OR
def pass; end
Note that it is useless to do this in Ruby since it allows empty methods but if you're that keen on pass, this is the simplest and cleanest alternative.
and now you can use this function inside any block and it will work the same.
def name
pass
end
# OR
class Name
pass
end
Keep in mind that pass is a function that returns, so it is up to you how you can use it.
If you want to be able to use it freely with any number of arguments, you have to have a small trick on the arguments:
def gobble *args, &pr; end
As others have said, in Ruby you can just leave a method body empty. However, this could prove a bit different than what Python accomplishes with pass.
In Ruby, everything is an object. The absence of value, which some programming languages indicate with null or nil is actually an object of NilClass in Ruby.
Consider the following example (in irb):
class A
def no_op
end
end
A.new.no_op
# => nil
A.new.no_op.class
# => NilClass
A.new.no_op.nil?
# => true
Here's Ruby's NilClass documentation for reference.
I believe Python's pass is used mainly to overcome the syntactic limitations of the language (indentation), although I'm not that experienced in Python.
Ruby's equivalent to pass can be ().
if 1 == 1
()
else
puts "Hello"
end
=> nil
lambda do
()
end.call
=> nil
You can also use it as part of condition ? true-expr : false-expr ternary operator.

Can I make ruby display method parameter values in a backtrace?

Using MRI 1.9
When an exception is raised that causes a backtrace to be printed, it would often be immensely easier to debug if the backtrace showed the receiver and values of method parameters as well as the method name. Is there any way of doing this?
Think about situations such as passing a nil deep into library code that wasn't expecting it, or where two strings have incompatible encodings and some routine is trying to concatenate them
you can with 1.8.6 by using the backtracer gem.
1.9 has slightly broken callbacks so isn't compatible yet, though. I might be able to get it to work, if desired.
You could use something like a delegate and see the parameters to a single object:
class A
def go a, b
end
end
class A2
def initialize *args
#delegate = A.new *args
end
def method_missing meth, *args
p "got call to #{meth}", args.join(', ')
#delegate.send(meth,*args)
end
end
which outputs
"in go2"
"got call to go"
"3, 4"

Ruby Methods: how to return an usage string when insufficient arguments are given

After I have created a serious bunch of classes (with initialize methods), I am loading these into IRb to test each of them. I do so by creating simple instances and calling their methods to learn their behavior. However sometimes I don't remember exactly what order I was supposed to give the arguments when I call the .new method on the class. It requires me to look back at the code. However, I think it should be easy enough to return a usage message, instead of seeing:
ArgumentError: wrong number of arguments (0 for 9)
So I prefer to return a string with the human readable arguments, by example using "puts" or just a return of a string. Now I have seen the rescue keyword inside begin-end code, but I wonder how I could catch the ArgumentError when the initialize method is called.
Thank you for your answers, feedback and comments!
It is possible to hook into object creation by overriding the Class#new method e.g.
class Class
# alias the original 'new' method before overriding it
alias_method :old_new, :new
def new(*args)
return old_new(*args)
rescue ArgumentError => ae
if respond_to?(:usage)
raise ArgumentError.new(usage)
else
raise ae
end
end
end
This overriden method calls the normal new method but catches ArgumentError and if the class of the object being created provides a usage method then it will raise an ArgumentError with the usage message otherwise it will reraise the original ArgumentError.
Here is an example of it in action. Define a Person class:
class Person
def initialize(name, age)
end
def self.usage
"Person.new should be called with 2 arguments: name and age"
end
end
and then try and instantiate it without the required arguments:
irb(main):019:0> p = Person.new
ArgumentError: Person.new should be called with 2 arguments: name and age
from (irb):8:in `new'
from (irb):22
Note: this isn't perfect. The main problem being that it is possible that the ArgumentError we catch has been caused by something other than an incorrect number of arguments being passed to initialize which would lead to a misleading message. However it should do what you want in most cases.

Resources