BetterErrors/better_errors

better_errors swallows rescue_from

Closed this issue ยท 9 comments

Hi there, I've noticed that better_errors intercepts the exception before rescue_from can get at it. This is on Rails 4.2 at least. Are you able to advise if there's a way around this?

This is almost certainly an exception being raised inside of your rescue_from block. Better Errors has an unfortunate shortcoming of displaying the second-most recent exception in a chain of exceptions. This is a known issue unfortunately.

The following results in "Rescued" being rendered to the browser.

class HomeController < ApplicationController
  rescue_from NameError do
    render plain: "Rescued"
  end

  def index
    invalid_method
  end
end

The following results in Better Errors reporting a NameError for invalid_method on line 9:

class HomeController < ApplicationController
  rescue_from NameError do
    a_different_invalid_method
    render plain: "Rescued"
  end

  def index
    invalid_method
  end
end

I don't have an easy workaround, but if you bundle open better_errors, open raised_exception.rb and change the line if exception.respond_to?(:cause) to if false && exception.respond_to?(:cause), you'll be able to get to the real exception.

Aha! I doubted you (because I was just doing a render call in the rescue_from. I disabled better_errors and got that feature working then just now tried turning it back on and what do you know! It works! :)

It's easy enough to disable better_errors in the future when developing rescue_froms. Thanks for the heads up, and hopefully this helps others who run into a similar situation :)

Ran into the same issue. Was wrecking my brains, until decided to disable all my error / debugging gems in development and it finally worked. Then came across this issue.

@RobinDaugherty Thanks for the suggestion. You were absolutely correct Better Error was eating up another error in rescue_from ( missing template) . Thank you!

@brendon, can we make this permanent? I've done it on my fork, however, it should be default.

@gencer, you'd need to talk to @RobinDaugherty :)

oh sorry, wrong tag :) thanks for the correction.

I'd love to fix this. It's a bit complicated though. Previously we showed the second error in the chain (cause of the topmost error) but that caused confusion in a number of cases. What we really need is to change the entire project to allow navigation up and down the chain. Unfortunately it's a large change, because it wasn't designed to support it.

Very well, I only use it on development so I made my own fork and prefixed that condition with false. It works and will continue to push changes there.

Until a solution found, I will fetch better_errors from my repo.

Just a note, this was fixed in Better Errors 2.7.0 (by #459).