How Star Trek into Darkness should have ended

Stop reading if you haven’t seen the movie yet, as obviously this will be a big spoiler.

I think Star Trek into Darkness should have ended with Kirk dead. I don’t care if they revive them in the next one, that’s fine. A friend told me:

I didn’t even realize that Kirk was dying, they wouldn’t kill him, it was just a small setback.

I think story tellers should be bolder and surprise us more.

I think they should have shown McCoy doing something with the body that can be later, in another movie, revealed as putting it in stasis. I think Spock shouldn’t have chased Kahn and have a fist fight. He should have been busy making sure the good of the many outweigh the revenge of the one by saving the Enterprise and making sure his crew was out of danger.

Hold on Pablo… you mean you want to end a movie with one of the main characters dead?

Yes, that would have been brave, although not new. Someone did it before and it might be familiar:

What about Kahn?

He should have run away. That’s it. Hold on… even better… he should have fled with his crippled ship.

But then… the bad guy won?

Yes. It would have been brave and it would have built a lot of tension and expectations for the next movie. Although, it wouldn’t have been the first franchise to have the bad guys win in one of their movies:

Advertisements

Wrapped exceptions in Ruby

Sometimes you want to raise an exception when a method fails but without losing information about an inner exception. Let me explain it with an example.

At Watu we have a method that causes a user to be indexed in our search engine. This method is called many times in different situations. One of those situations is when indexing most or all of our users. Recently, something failed and I got this exception:

undefined method `each' for #<String:0x10dab8fc>

Something that should be an array is actually a string. In this case the indexing method is correct, it’s just getting broken data. I want to fix the bug in the data generation, but to locate it, I need to know which user has broken data. I added a rescue clause to my indexing method to show me that data:

def index
  # ...
rescue
  raise "Error when indexing user #{self}"
end

Now I get something like:

Error when indexing user #<User:1234>

which allows me know that user 1234 has something wrong in its data. The problem is that now I have no idea what the issue is. I lost the information about trying to call each on a string.

The solution to this problem is exception wrapping (or nesting). You want the custom exception to wrap the other one so that you have both pieces of information. This, for example, exists in Java and if you search the web you’ll find ways on how to implement it in Ruby. Implementing this manually is not needed anymore since Ruby 2.1. Unfortunately, it’s a bit hidden and the tools haven’t caught up yet.

The secret lies in a new method in the class Exception called, cause. At the time of this writing it doesn’t even have documentation:

No documentation for the method Exception#cause
No documentation for the method Exception#cause

Using it is very straightforward. Just raise an exception in the rescue clause and the new exception will have the previous one as its cause. For example, in this case:

begin
  a = 1 / 0
rescue
  raise "Something went wrong"
end

you get two exceptions: the divided-by-zero wrapped inside one with the “Something went wrong” message.

The problem arrises that nobody seems to be using the causes of exceptions yet. If you run that in IRB, this is what you get:

RuntimeError: Something went wrong
        from (irb):4:in `rescue in irb_binding'
        from (irb):1
        from /Users/pupeno/.rvm/rubies/ruby-2.1.0/bin/irb:11:in `&lt;main&gt;'

But the exception’s cause is in there… hidden. If you catch the outer exception you can access its cause. For example:

begin
  begin
    a = 1 / 0
  rescue
    raise "Something went wrong"
  end
rescue => e
  puts e
  puts e.cause
end

would produce:

Something went wrong
divided by 0

The reason why it doesn’t produce something like that by default is because whatever IRB is using to print exceptions is ignoring the exception’s cause. Now we’ll have to wait until all the tools catch up with this new feature.

Well, we don’t actually have to wait. Aside from the fact that most of them are open source and you can fix them yourself, Ruby allows you to monkey patch so you can fix your own copy of these tools.

In my case I needed rake to print inner exceptions, so I wrote this monkey patch (which works for rake 10.1.1):

module Rake
  class Application
    def display_error_message(ex)
      trace "#{name} aborted!"
      display_exception(ex)
      trace "Tasks: #{ex.chain}" if has_chain?(ex)
      trace "(See full trace by running task with --trace)" unless options.backtrace
    end

    private

    def display_exception(ex, margin="")
      trace "#{margin}#{ex.message}"
      if options.backtrace
        trace "#{margin}#{ex.backtrace.join("\n#{margin}")}"
      else
        trace "#{margin}#{Backtrace.collapse(ex.backtrace).join("\n#{margin}")}"
      end
      if ex.respond_to?(:cause) && !ex.cause.nil? # Ruby < 2.1.0 doesn't have *cause*
        trace "#{margin}which was caused by:"
        display_exception(ex.cause, "#{margin} ")
      end
    end
  end
end

This is something that I would like to see in rake itself so I created an issue request (#253). Take a look at it to follow the development of this feature and hopefully, all tools will start displaying causes in one way or another.