Closed p8 closed 4 years ago
Hmm, I don't think we should ever add a recsue
that broadly catches errors like this unless there is a strong reason to do so. If there is a failure, it should simply just be fixed. What are the errors you have seen?
I'm not a fan of the rescue
either. 😄 There already is a rescue
in the to_s
and I wonder if that rescues errors caused by calling corrections
in most cases.
I was trying to call corrections
in the Rails error templates but the following test failed with a "No receiver" ArgumentError. It currently works because to_s
rescues the error. So you won't see any suggestions.
https://github.com/rails/rails/blob/master/actionpack/test/dispatch/debug_exceptions_test.rb#L367
I'm closing this issue. If there is an issue in the code you actively work on, it should just be fixed there rather than silently falling back to the original behavior in DYM. I'll follow up on the rails/rails side.
So the "No receiver" ArgumentError
was caused by an incorrect override of ParameterMissing#initialize.
Instead of:
def initialize(param, keys = nil)
It should have matched the superclass KeyError#initialize:
def initialize(param, receiver: nil)
If an error is raised in Correctable#to_s it is rescued and the super method is called instead. If Correctable#corrections is called it should be rescued as well and return an empty array.
This allows 3rd party gems to customize how suggestions are displayed:
I'm trying to use
#original_message
and#corrections
in the Rails error pages (https://github.com/rails/rails/pull/39363), but calling#corrections
sometimes fails while#to_s
works (but it doesn't show the suggestions).