rails if object.nil? then magic '' in views?

Question

This is one of those things, that maybe so simple I\'ll never find it because everyone else already knows it.

I\'ve got objects I have to check for nil in my views s

Answer 1

Another option, which makes sense occasionally...

If tax_payment.user returns nil, nil.to_s (an empty string) is printed, which is harmless. If there is a user, it will print the user's name.

Answer 2

What about:

<%= tax_payment.user.name if tax_payment.user %>

Answer 3

The Ruby community has put an incredible amount of attention to automating this idiom. These are the solutions I know of:

• try in Ruby on Rails
• Another try
• andand
• A safer andand
• Kernel::ergo
• send-with-default
• maybe
• _?
• if-not-nil
• turtles!
• method_ in Groovy style
• do-or-do-not

The most well-known is probably the try method in Rails. However, it has received some criticism.

In any case, I think Ben's solution is perfectly sufficient.

Answer 4

I just do

<%= tax_payment.user.name rescue '' %>

Answer 5

You could write a helper method which looks like this:

def print_if_present(var)
    var ? var : ""
end

And then use it like this (in the view):

<%= print_if_present(your_var) %>

If the var is nil, it just prints nothing without raising an exception.

Answer 6

For a little more comprehensive solution, you could check out the Introduce Null Object Refactoring. The basic mechanics of this refactoring is that instead of checking for nil in the client code you instead make sure that the provider never produces a nil in the first place, by introducing a context-specific null object and returning that.

So, return an empty string, an empty array, an empty hash or a special empty customer or empty user or something instead of just nil and then you will never need to check for nil in the first place.

So, in your case you would have something like

class NullUser < User
    def name
        return ''
    end
end

However, in Ruby there is actually another, quite elegant, way of implementing the Introduce Null Object Refactoring: you don't actually need to introduce a Null Object, because nil is already an object! So, you could monkey-patch nil to behave as a NullUser – however, all the usual warnings and pitfalls regarding monkey-patching apply even more strongly in this case, since making nil silently swallow NoMethodErrors or something like that can totally mess up your debugging experience and make it really hard to track down cases where there is a nil that shouldn't be there (as opposed to a nil that serves as a Null Object).