I'm a Floridian web engineer who planted his roots in Paris. Some of my favorite past-times are analyzing and optimizing development processes, building solid APIs, mentoring junior devs, and long walks on the beach.

Exceptional code 01-22-2017

When I started programming, I never gave much thought to exceptions. I did not realize the benefit. If you write mainly interpreted scripts, they may seem like any other error that explodes during execution. Of course the difference, is that they are controlled explosions.

Some of the primary benefits are that they:

  • Allow you to expect some sort of known potential failure.
  • Allow you to know where the failure came from.
  • Allow you to fail gracefully.

The bad and the ugly

One of the worst things that I've seen is what follows:

def source

The problem here, is that instead of handling failure, we just ignore it. There is no way to know what happens or why it happens. If risky_business normally returns nil, we may also think that function has passed when it really fails.

The next snippit is better, but still not without its problems.

def source
  raise "The source of all your problems"

def bad_exception_catcher
  rescue Exception => e
    raise e.message

The problem here is a little more subtle. It is clear that we are taking advantage of being able to clean up problem code, however, there is one key problem. We are creating a new exception when we "raise e.message". This means that later in the logs, this call will be the source of the backtrace and not the original source function. If our source function is just one line, then there is no problem, but the more complicated that source function is, the more difficult it will be to pinpoint the problem.

A way to get around this problem, is to just reraise the original exception. In that way we will keep the original backtrace history.

def bad_exception_catcher
  rescue Exception => e
    raise e


Typically, exceptions are something that you can and should test for. Also, if you are using ruby and something like rspec, exception testing is supported out of the box.

it "should raise error if user has no email" do
  user = OpenStruct.new(email: nil, name: 'A. Person', uid: 10244201)
  expect { user = User.facebook_get_user('access_token') }.to raise_exception(
    LoginException, 'Please use an account with a valid email'

In testing for specific exceptions, you can also assure that you don't get unexpected exceptions.

Definition vs Function/Methods Style 10-15-2011

I was recently reading The Rails 3 way by Obie Fernandez when I came across a section of the book that was talking about how Ruby allows for a definition-style as opposed to a funtion-style. That is to say, using a function call without including the open and closing parentheses. Typically, I like using functions without parentheses because I feel that the function looks more clear.

I much prefer to see:

link_to "Some page", some_page_path

instead of:

link_to( "Some page", some_page_path )

Especially in a haml template, the first style looks nicer. However, "The Rails 3 way" mentions that one of the key benefits parenthesis-less function calls offer is macro-like feeling and should be a signifier that this call will affect other things and not act directly. Indeed when you look at the following code:

class Client < ActiveRecord::Base 
  has_many :billing_codes
  has_many :billable_weeks
  has_many :timesheets, :through => :billable_weeks

class Client < ActiveRecord::Base
  has_many(:timesheets, :through => :billable_weeks)

You can see that the first one looks cleaner. It also looks more like a declaration. Indeed, the has_many function alters the object of the class that calls it giving all of it's instantiated objects a slew of other functions. This theme happens over and over again in the Rails framework. The filters that are added to controllers, such as before_filter and after_filter, will alter the functionality of actions that get called.


The problem with the definition-style method is when there are nested functions which take parameters. For instance, if the function for generating the page for some_page requires parameters as well:

some_page_path( :user_id => current_user.id, :name => 'derp' ) # calls the path for some page

This will cause problems when the following call is made:

link_to "Some page", some_page_path :user_id => current_user.id, :name => 'derp'

In the link_to call, it can't be determined whether the :name parameter should be part of the params for link_to or part of the params for some_page_path.

Since consistency is always preferred, it is better to always use parentheses with function calls only leave them off only when the function is being used to alter the class in some way.

Tags: style ruby Rails

Names n Stuff 09-18-2011

A few days ago, where I work, there was an argument over whether the following function should exist:

def is_premium_or_has_receipt_for?(product)
  self.premium_member? || self.store.has_receipt?(product)

I had a hard time explaining myself as to why I thought the function should not exist. At first all I could think of was, "This seems like a bad idea." Then I ran into a similar piece of code today and it became clear to me.

The function should exist, but there is a problem with the name. It simply restates what the logic is. When writing functions one of the benefits is that it allows you to group a bunch of smaller ideas into a bigger one. In this scenario we are merely re-writing an if clause in a prettier fashion; But the lines of code together are conveying a higher level idea. What the function is actually saying is "return true if the user has access to the following product".

So the function should look something like:

can_use_product? product
Tags: ruby

Testing File operations 03-24-2011

I've recently been working on a gem that will integrate git and pivotal into my current command-line workflow. I'll talk more about that in a future post, but check it out if you're interested. As I've been working on it, I have become increasingly aware how awesome mocking and stubbing are. I've been using mocha(gem install mocha #bros) for all of my needs and after a little playing around it has made me a very happy person. I haven't had much use for either until this gem I've been working on. The gem does more file operations that I normally do since most web stuff is heavier on the db action.

On this project I ran into an issue where I wasn't sure how to test the following code.

def load_project_id
  File.open('.git/config') do |file| 
    file.each_line do |line| 
      if line.slice('[pivotal]')
        return file.gets.tr("\s\t\n",'').split(' = ').last

For this chunk of code, I wanted to spoof the variable 'file' so that I could make sure that everything in the File.open block does what it needs to. At first I thought that there might be a way to stub the variable that comes in to the block, but it ends up there is a more straight forward thing to do. I ended up turning File.open(".git/config") into File.open(git_config) where git_config is a method that determines the git config directory based on the current working directory. This way I can test this method by stubbing the git_config method with some file I've put in the /tmp directory and keep my config files clean.

Dot-Rspec files 03-02-2011

I was recently working on a small library for assigning people a schedule and I decided to go with rspec 2 for testing. As I was working with it, I found that you can use a .rspec file to keep all of the settings in which seemed like a good idea to me. I'm used to having config files like that what with .bashrc, .rvmrc, etc. My file was laid out as such:

--format documentation

I could then run the command rspec spec/libs/* and it would run all of my tests in the desired format. I didn't want to have to specify the directory every time and so I decided to add the -I option in my .rspec file to include the directory. This, for some reason, would not work and while looking for a solution, I found the rspec 1 to 2 upgrade page with my answer.

Create a Rake Task

Under rake task it lists how you can set the options using a Rakefile, which in retrospec(...har), I should have been using anyways. I ended up using something like the following:

require 'rspec/core/rake_task'
RSpec::Core::RakeTask.new do |t|
    t.rspec_opts = ["--color", "--format documentation", "--fail-fast"]
    t.pattern = ['spec/libs/*.rb']

Now I can call my tests with rake spec.

Moral of the Story

Don't use .rspec for your rspec configurations. You'll probably end up needing a Rakefile at some point anyways so you might as well use that.

Tags: rspec ruby