[rspec-devel] [cucumber] lib/cucumber/rails/world.rb redefining ActionController::Base#rescue_action

Aslak Hellesøy aslak.hellesoy at gmail.com
Tue Mar 24 20:14:49 EDT 2009



Den 25. mars. 2009 kl. 00.04 skrev Zach Dennis <zach.dennis at gmail.com>:

> 2009/3/24 aslak hellesoy <aslak.hellesoy at gmail.com>:
>>
>>
>> On Tue, Mar 24, 2009 at 10:46 PM, Matt Patterson
>> <matt-lists at reprocessed.org> wrote:
>>>
>>> Evening.
>>>
>>> I've got a question about the redefinition of
>>> ActionController::Base#rescue_action. Mainly, why? From the  
>>> comment in the
>>> source it looks there was a pain point that this solved, but I  
>>> can't figure
>>> out what that might be.
>>>
>>> My problem is this: I make heavy use of rescue_from to trap  
>>> exceptional
>>> cases so I can 404, 401 or 500 as appropriate. I've got a Scenario  
>>> which
>>> looks like this ('deleted' blog posts in this app aren't erased  
>>> from the DB,
>>> they're marked deleted for auditing):
>>>
>>>  Scenario: Attempting to visit a deleted blog post
>>>    Given there is a blog post entitled "Look Ma no hands"
>>>    And the blog post "Look Ma no hands" has been marked as deleted
>>>    When I attempt to visit the Blog post page for "Look Ma no hands"
>>>    Then the response should be a 404 error
>>>
>>> That looks like a perfectly reasonable scenario to me, except that  
>>> it
>>> blows up at "When I attempt to visit". The source for that step is:
>>>
>>> When /^I attempt to visit the Blog post page for "(.+)"$/ do |title|
>>>  visit entry_path(Entry.find_by_url_slug! 
>>> (Digest::MD5.hexdigest(title)))
>>> end
>>>
>>> [Excuse the MD5 - it's just a way of maintaining readability in the
>>> scenarios without resorting to fixtures (I'm undecided about it as  
>>> an
>>> approach, btw)]
>>>
>>> visit is exploding when my controller raises a FourOhFour error  
>>> because a
>>> non-staff non-logged-in user shouldn't be able to see the page. I  
>>> use
>>> rescue_from to render a special 404 template, but that's never  
>>> reached
>>> because of the redefinition of rescue_action.
>>>
>>> This seems really counterintuitive to me: I expect that the  
>>> integration
>>> tests will use the full stack, and even in my isolated controller  
>>> specs I
>>> have to explicitly request that the normal rescue_action is  
>>> bypassed. If
>>> there's a genuine pain point here that re-raising and not handling  
>>> the
>>> exception solves then I'm sure I can find a different idiom for  
>>> these kinds
>>> of scenarios, but I've spent 4 hours today trying to figure out  
>>> what was
>>> broken: first in my app code then breaking out rdebug to find out  
>>> what was
>>> really happening, which suggests to me that it's a non-obvious and  
>>> confusing
>>> intervention.
>>>
>>> Anyway, sorry to sound so whingey. Like I said: if there's a genuine
>>> problem this approach solves, I'll find a new idiom and shut up.  
>>> Otherwise,
>>> can this be changed?
>
> I usually comment those things out in rails/world.rb in cucumber.
>
>>
>> I understand your situation - it's perfectly valid. Still, I think  
>> you are
>> the first person to bring this up.
>
> Nope, he's not:
>
> http://www.ruby-forum.com/topic/177887

Doh. Forgot.
>
>
>> The vast majority of Cucumber users/Rails
>> developers don't rely on this kind of error handling, so raising  
>> errors
>> seems to be a sensible default.
>
> I'm not the vast, but I rely on, and I know several other Rails devs
> who rely on it to. Although, we may still be the minority.
>
>>
>> There is currently no way to turn off that default. Can you provide  
>> a patch
>> (or a suggestion) that will let users optionally turn off the current
>> behaviour?
>
> A discussion was originally brought up here:
>
> http://rspec.lighthouseapp.com/projects/16211/tickets/49-cucumber-and-rails-controller-error-handling
>
> I apologize for not being proactive on my end, so far taking out the
> offending lines on rails/world.rb has worked fine.
>
>>
>> Aslak
>>
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>> --
>>>  Matt Patterson | Design & Code
>>>  <matt at reprocessed org> | http://www.reprocessed.org/
>>>
>>>
>>>
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>>
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>
>
>
> -- 
> Zach Dennis
> http://www.continuousthinking.com
> http://www.mutuallyhuman.com
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


More information about the rspec-devel mailing list