Raising custom exceptions in Rails

Alright, thanks… I actually am including the module in the corresponding controllers, I just left that part out.

Exceptions are called exceptions for a reason, they should only happen during “exceptional” conditions and should NEVER be used as normal flow control.

Exception handling adds a ton of overhead to the code. Your examples went from a predictable if/else block (certain processors will be able to ‘guess’ the right jump to make, meaning there is no delay) to something that takes many more cycles.

I hear you about the dynamic language part, but I want to stress that this isn’t an order of nanoseconds we’re talking about. Sure, if this is an oft-unused code path we’re talking about, you can get away with it, but if this is in a portion of code that gets hit a lot, then we’re talking orders of magnitude slower.

For example, I wrote a simple app that follows your two examples above, both count the number of even numbers between 0 and 100,000. below are the ‘time’ results:

> time ruby if.rb
Found 50000 even numbers

real 0m0.065s
user 0m0.036s
sys 0m0.008s
-———————————-
> time ruby ex.rb
Found 50000 even numbers

real 0m1.110s
user 0m0.540s
sys 0m0.040s

as you can see, the code that uses exceptions takes over 17 times longer! just another thing to think about in this wonderful world of coding :)

Your “we hate IE6” code is borked!!!! I’m using IE8 and it gave me hate messages :(

I realize this is an older post, but I thought i’d mention… In Matz’s recent Google Tech Talk on Ruby 1.9, he specifically warns that perf in exception handling (for 1.9) has been sacrificed to some extent in favor of gaining better perf in the normal code path.

http://www.youtube.com/watch?v=oEkJvvGEtB4

His almost exact quote was: “This makes sense because exceptions are exceptional.”

I definitely use patterns like “rescue nil” that maybe abuse the intent of exceptions a little bit, but it’s good to be thoughtful in hot code paths.

Akira… what is more expensive in the “real world” – another box in the cluster or another developer sitting at a desk? They don’t want to “code less” they want to code BETTER. You exhibit the typical “know it all” attitude from a overly eager college student who has not ever had a real job in the software industry and does not understand the MASSIVE overhead of maintaining bad, hard to read code. Rails developers care about “coding less” because that is usually the cleanest and most maintainable way to go about things.

I am sure there are companies out there who don’t place value on code quality – simply on performance, but those places usually resemble dilbert’s office and is no where i would want to spend my waking hours.

I still tend to use this pattern occasionally. I realize (mainly thanks to Andy in comment #6) that this can indeed slow down code execution. And I would completely consider an alternate route if it came down to the point where I had to squeeze every last bit of performance out of an application.

But, typically, I’m not to that point with any of the applications that I work with.

From my experience, if I set out to improve performance on any Rails application, it always seems to start at the db level with query optimization and ensuring things like proper use of :include (as Jen suggested in comment #13). Then I typically review how I’m caching things, and improve upon that if need be.

I appreciate the awareness of how costly something like exception handling in this manner can be, but I honestly can’t say that I’m willing to change those types of things without first tackling performance issues in other areas. I’m not trying to be ignorant about the issue, it’s just at matter of preference. And those who disagree will always have the satisfaction of knowing that their app will be that much faster than mine :-)

I think the “more readable code vs. performance” argument will never be resolved, and surely not here within these comments. But nevertheless, it’s interesting to hear other perspectives on the matter.

Personally I think the use of an exception makes it harder to follow the logic when reading the code for the first time in this case. In a way it’s a nice idea, and I really appreciate the desire to get more concise and readable. But concise, readable code isn’t just shorter or written on fewer lines. It actually relects logical elegance, in exactly the same way that a good essay would. If your thinking can be made clearer in the code, that makes it easier to maintain as well. Given the code example above, something like:

def do_some_work
  if !feeling_lazy?
    do_work_for(current_user)
    flash[:notice] = "Glad you're working hard." 
  else
    redirect_to lazy_page_path
    flash[:error] = "You're too lazy to work here." 
  end
end

where the user-specific logic is moved into another method that wraps the functionality of the other two, is much easier for me to parse because it combines three things that go together (those two ‘work’ methods, and the user that is associated with them) into one semantic space. Furthermore, the two ‘work’ methods are likely to contain opportunities for code deduplication as well, given their titles and association with the user object.

Jay -

When you rescue an error you’re rescuing an instance of that error, and like any instance of any object, it has methods. That said, you could do something like this:

1
2
3
4
5
6
7

module Exceptions
  class TooLazyToWork < StandardError
    def message
      "Get back to your Cubicle!"
    end
  end
end

Then you could have something like this:

1
2
3
4
5
6
7
8

begin
  raise Exceptions::TooLazyToWork if feeling_lazy?

  # do some other stuff

rescue Exceptions::TooLazyToWork => e
  flash[:error] = e.message # "Get back to your Cubicle!"
end

Does that solve your problem?

@Graham Ashton -

Thanks for the response, I appreciate it. And over the years, my findings have been exactly the same. I’m not willing to trade the cleanliness (in my opinion, at least) of handling exceptions this way for picking up an extra nanosecond here and there.