So I'm trying to get a class out of the value of the class:
bucket.product_name.constantize #=> want to check if that fails
However sometimes the application bugs me with:
NameError: wrong constant name a
So I assume there is some weird product_names that has either nil value or corrupted value: such as a.
How would you check if that is NameError issue?
Say,
"a".constantize if "a".constantize != NameError
defined?("a") == "constant"
# => true if "a" is a valid constant name
# => false otherwise
Using this:
name = bucket.product_name
name.constantize if defined?(name) == "constant"
This is too obvious, but just in case:
begin
"a".constantize
rescue NameError
# handle error here
end
Related
I recently read a blog post about Ruby's behaviours with regards to a local variable shadowing a method (different to, say, a block variable shadowing a method local variable, which is also talked about in this StackOverflow thread), and I found some behaviour that I don't quite understand.
Ruby's documentation says that:
[V]ariable names and method names are nearly identical. If you have not assigned to one of these ambiguous names ruby will assume you wish to call a method. Once you have assigned to the name ruby will assume you wish to reference a local variable.
So, given the following example class
# person.rb
class Person
attr_accessor :name
def initialize(name = nil)
#name = name
end
def say_name
if name.nil?
name = "Unknown"
end
puts "My name is #{name.inspect}"
end
end
and given what I now know from reading the information from the links above, I would expect the following:
The name.nil? statement would still refer to the name instance method provided by attr_accessor
When the Ruby parser sees the name = "Unknown" assignment line in the #say_name method, it will consider any reference to name used after the assignment to refer to the local variable
Therefore, even if the Person had a name assigned to it on initialisation, the name referenced in the final line of #say_name method would be nil
And it looks like this can be confirmed in an irb console:
irb(main):001:0> require "./person.rb"
true
# `name.nil?` using instance method fails,
# `name` local variable not assigned
irb(main):002:0> Person.new("Paul").say_name
My name is nil
nil
# `name.nil?` using instance method succeeds
# as no name given on initialisation,
# `name` local variable gets assigned
irb(main):003:0> Person.new.say_name
My name is "Unknown"
nil
However, if I do some inline debugging and use Pry to attempt to trace how the referencing of name changes, I get the following:
irb(main):002:0> Person.new("Paul").say_name
From: /Users/paul/person.rb # line 13 Person#say_name:
10: def say_name
11: binding.pry
12:
=> 13: p name
14: if name.nil?
15: name = "Unknown"
16: end
17:
18: puts "My name is #{name.inspect}"
19: end
[1] pry(#<Person>)> next
"Paul"
Okay, that makes sense as I'm assuming name is referring to the instance method. So, let's check the value of name directly...
From: /Users/paul/person.rb # line 14 Person#say_name:
10: def say_name
11: binding.pry
12:
13: p name
=> 14: if name.nil?
15: name = "Unknown"
16: end
17:
18: puts "My name is #{name.inspect}"
19: end
[2] pry(#<Person>)> name
nil
Err... that was unexpected at this point. I'm currently looking at a reference to name above the assignment line, so I would have thought it would still reference the instance method and not the local variable, so now I'm confused... I guess somehow the name = "Unknown" assignment will run, then...?
[3] pry(#<Person>)> exit
My name is nil
nil
Nope, same return value as before. So, what is going on here?
Was I wrong in my assumptions about name.nil? referencing the name instance method? What is it referencing?
Is all this something related to being in the Pry environment?
Something else I've missed?
For reference:
➜ [ruby]$ ruby -v
ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-darwin16]
Edit
The example code in this question is meant to be illustrative of the (I think) unexpected behaviour I'm seeing, and not in any way illustrative of actual good code.
I know that this shadowing issue is easily avoided by re-naming the local variable to something else.
Even with the shadowing, I know that it is still possible to avoid the problem by specifically invoking the method, rather than reference the local variable, with self.name or name().
Playing around with this further, I'm starting to think it's perhaps an issue around Pry's environment. When running Person.new("Paul").say_name:
From: /Users/paul/person.rb # line 13 Person#say_name:
10: def say_name
11: binding.pry
12:
=> 13: p name
14: if name.nil?
15: name = "Unknown"
16: end
17:
18: puts "My name is #{name.inspect}"
19: end
At this point, the p statement hasn't run yet, so let's see what Pry says the value of name is:
[1] pry(#<Person>)> name
nil
This is unexpected given that Ruby's documentation says that since no assignment has been made yet, the method call should be invoked. Let's now let the p statement run...
[2] pry(#<Person>)> next
"Paul"
...and the value of the method name is returned, which is expected.
So, what is Pry seeing here? Is it modifying the scope somehow? Why is it that when Pry runs name it gives a different return value to when Ruby itself runs name?
Once Ruby has decided that name is a variable and not a method call that information applies to the totality of the scope it appears within. In this case it's taking it to mean the whole method. The trouble is if you have a method and a variable with the same name the variable only seems to take hold on the line where the variable has been potentially assigned to and this re-interpretation affects all subsequent lines within that method.
Unlike in other languages where method calls are made clear either by some kind of prefix, suffix or other indicator, in Ruby name the variable and name the method call look identical in code and the only difference is how they're interpreted at "compile" time proior to execution.
So what's happening here is a little confusing and subtle but you can see how name is being interpreted with local_variables:
def say_name_local_variable
p defined?(name) # => "method"
p local_variables # => [:name] so Ruby's aware of the variable already
if name.nil? # <- Method call
name = "Unknown" # ** From this point on name refers to the variable
end # even if this block never runs.
p defined?(name) # => "local-variable"
p name # <- Variable value
puts "My name is #{name.inspect}"
end
I'm quite surprised that, given how obnoxiously particular Ruby can be with the -w flag enabled, that this particular situation generates no warnings at all. This is likely something the'll have to emit a warning for, a strange partial shadowing of methods with variables.
To avoid method ambiguity you'll need to prefix it to force it to be a method call:
def say_name
name = self.name || 'Unknown'
puts "My name is #{name.inspect}"
end
One thing to note here is that in Ruby there are only two logically false values, literal nil and false. Everything else, including empty strings, 0, empty arrays and hashes, or objects of any kind are logically true. That means unless there's a chance name is valid as literal false then || is fine for defaults.
Using nil? is only necessary when you're trying to distinguish between nil and false, a situation that might arise if you have a three-state checkbox, checked, unchecked, or no answer given yet.
What looks like inconsistent return values for name during runtime and while debugging doesn't seem to related to Pry, but more about binding itself encapsulating the entire execution context of a method, versus the progressive change in what shadowed variables reference at runtime. To build on the example method with some more debugging code:
def say_name
puts "--- Before assignment of name: ---"
puts "defined?(name) : #{defined?(name).inspect}"
puts "binding.local_variable_defined?(:name) : #{binding.local_variable_defined?(:name).inspect}"
puts "local_variables : #{local_variables.inspect}"
puts "binding.local_variables : #{binding.local_variables.inspect}"
puts "name : #{name.inspect}"
puts "binding.eval('name') : #{binding.eval('name').inspect}"
if name.nil?
name = "Unknown"
end
puts "--- After assignment of name: ---"
puts "defined?(name) : #{defined?(name).inspect}"
puts "binding.local_variable_defined?(:name) : #{binding.local_variable_defined?(:name).inspect}"
puts "local_variables : #{local_variables.inspect}"
puts "binding.local_variables : #{binding.local_variables.inspect}"
puts "name : #{name.inspect}"
puts "binding.eval('name') : #{binding.eval('name').inspect}"
puts "My name is #{name.inspect}"
end
Now, running Person.new("Paul").say_name outputs:
--- Before assignment of name: ---
defined?(name) : "method"
binding.local_variable_defined?(:name) : true
local_variables : [:name]
binding.local_variables : [:name]
name : "Paul"
binding.eval('name') : nil
--- After assignment of name: ---
defined?(name) : "local-variable"
binding.local_variable_defined?(:name) : true
local_variables : [:name]
binding.local_variables : [:name]
name : nil
binding.eval('name') : nil
My name is nil
which shows that binding never references the method call of name and only ever the eventually-assigned name variable.
My Rails website (this problem is purely Ruby based though) uses the AWS-SES (Action mailer using AWS) gem in test/development environment, and I am catching possible errors from email deliveries like this
def try_delivering_email(options = {})
begin
yield
return false
rescue EOFError,
...
AWS::SES::ResponseError,
... => e
log_exception(e, options)
return e
end
end
Now the problem is that this gem is only defined for specific environments, in other words AWS does not exist in development, and the error checking code will therefore throw an error (haha) for undefined constant.
I have tried substuting that line for (AWS::SES::ResponseError if defined?(AWS) but then the next error I get is
class or module required for rescue clause
How can I get around this in the nicest way possible ?
The exception list of a rescue-clause doesn't have to be a literal/static list:
excs = [EOFError]
defined?(AWS) && excs << AWS::SES::Response
# ...
rescue *excs => e
The splat operator * is used here to convert an array into a list.
You can't include a conditional in a rescue clause, but you can blind rescue and then get picky about how to deal with it using conventional Ruby code:
rescue EOFError => e
log_exception(e)
e
rescue => e
if (defined?(AWS) and e.is_a?(AWS::SES::Response))
# ...
else
raise e
end
end
It's not the nicest way, but it does the job. You could always encapsulate a lot of that into some module that tests more neatly:
def loggable_exception?(e)
case (e)
when EOFError, AnotherError, EtcError
true
else
if (defined?(AWS) and e.is_a?(AWS::SES::Response))
true
else
false
end
end
end
Then you can do this as that method name should be self-explanatory:
rescue => e
if (loggable_exception?(e))
log_exception(e)
e
else
raise e
end
end
You could make this a little neater if log_exception returned the exception it was given. Don't forget Ruby is "return by default" and it doesn't need to be explicit unless you're doing it early.
I'm writing a helper to check if a given class exists.
def safe_constant(constant_sym)
return Object.const_get(constant_sym) if Object.const_defined? constant_sym
end
This works just fine for something like safe_constant(:User)
However, we have a number of objects that are namespaced in modules
safe_constant(:Admin::User) is obviously not a valid symbol. I know I could determine if this exists by doing:
Object.const_get(:Admin).const_get(:User) but before I go writing some kind of split loop drill-down method to get the final constant, is there any standard way to handling this already?
According to Ruby API document, it's possible to get const_defined? and const_get working with namespace string to check and return the class constant. What needs to be done is passing the second argument (inherit) as false, for example:
class User; end
module Admin
class User; end
end
Object.const_defined?('Admin::User', false) # => true
Object.const_get('Admin::User', false) # => Admin::User
PS: const_defined? and const_get do not accept namespaced Symbol and will raise NameError exception, for example:
# namespaced String
Object.const_defined?('Admin::User', false) # => true
# namespaced Symbol
Object.const_defined?(:'Admin::User', false)
# => NameError (wrong constant name Admin::User)
How about something like this?
def safe_constant(constant_sym)
return constant_sym.to_s.constantize if valid_constant? constant_sym.to_s
end
def valid_constant?(const)
const.constantize
return true
rescue NameError
return false
end
When I call Exception#backtrace_locations, it usually returns an array, as intended:
begin
raise "foo"
rescue => e
p e.backtrace_locations
end
# => ["this_file:2:in `<main>'"]
This is the same if I raise an ArgumentError manually:
begin
raise ArgumentError.new
rescue => e
p e.backtrace_locations
end
# => ["this_file:2:in `<main>'"]
However, when I raise a real ArgumentError by calling a method with wrong number of arguments, the backtrace_locations is nil, which is unexpected to me:
def foo; end
begin
foo(:bar)
rescue => e
p e.backtrace_locations
end
# => nil
Under the same situation, the classic Exception#backtrace returns an array, as intended:
def foo; end
begin
foo(:bar)
rescue => e
p e.backtrace
end
# => ["this_file:1:in `foo'", "this_file:4:in `<main>'"]
Is the return value of Exception#backtrace_locations being nil in the third case above intended? If so, when does Exception#backtrace_locations become nil? Is there any documentation for this? Or, is it a Ruby bug?
At this point, I think it is a bug, and reported it.
It was a bug, and the maintainer ko1 just fixed it in Revision 44411. Hopefully, it will make it into the release of Ruby 2.1 today.
Edit Turns out that it has not been fixed yet. Ruby 2.1 released today still has this issue.
Edit According to a maintainer, the fix will be incorporated into Ruby 2.1.1.
I want to be able to rescue I18n::MissingTranslationData like so:
begin
value = I18n.t('some.key.that.does.not.exist')
puts value
return value if value
rescue I18n::MissingTranslationData
puts "Kaboom!"
end
I tried the above, but it doesn't seem to go into the rescue block. I just see, on my console (because of puts): translation missing: some.key.that.does.not.exist. I never see Kaboom!.
How do I get this to work?
IMO, it's pretty strange but in the current version of i18n (0.5.0) you should pass an exception that you want to rescue:
require 'i18n'
begin
value = I18n.translate('some.key.that.does.not.exist', :raise => I18n::MissingTranslationData)
puts value
return value if value
rescue I18n::MissingTranslationData
puts "Kaboom!"
end
and it will be fixed in the future 0.6 release (you can test it - https://github.com/svenfuchs/i18n)
Same as above but nicer.
v = "doesnt_exist"
begin
puts I18n.t "langs.#{v}", raise: true
rescue
puts "Nooo #{v} has no Translation!"
end
or
puts I18n.t("langs.#{v}", default: "No Translation!")
or
a = I18n.t "langs.#{v}", raise: true rescue false
unless a
puts "Update your YAML!"
end
In the current version of I18n, the exception you're looking for is actually called MissingTranslation. The default exception handler for I18n rescues it silently, and just passes it up to ArgumentError to print an error message and not much else. If you actually want the error thrown, you'll need to override the handler.
See the source code for i18n exceptions, and section 6.2 of RailsGuides guide to I18n for how to write a custom handler
Note that now you simply pass in :raise => true
assert_raise(I18n::MissingTranslationData) { I18n.t(:missing, :raise => true) }
...which will raise I18n::MissingTranslationData.
See https://github.com/svenfuchs/i18n/blob/master/lib/i18n/tests/lookup.rb