Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

better_errors swallows rescue_from #424

Closed
brendon opened this issue Jul 8, 2018 · 9 comments
Closed

better_errors swallows rescue_from #424

brendon opened this issue Jul 8, 2018 · 9 comments

Comments

@brendon
Copy link

brendon commented Jul 8, 2018

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?

@RobinDaugherty
Copy link
Member

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.

@brendon
Copy link
Author

brendon commented Jul 12, 2018

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 :)

@brendon brendon closed this as completed Jul 12, 2018
@konung
Copy link

konung commented Sep 6, 2018

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!

@gencer
Copy link

gencer commented Feb 10, 2019

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

@brendon
Copy link
Author

brendon commented Feb 10, 2019

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

@gencer
Copy link

gencer commented Feb 10, 2019

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

@RobinDaugherty
Copy link
Member

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.

@gencer
Copy link

gencer commented Feb 11, 2019

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.

@RobinDaugherty
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants