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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle TypeError from where filter gracefully #9292

Merged
merged 5 commits into from Mar 24, 2023

Conversation

ashmaroli
Copy link
Member

@ashmaroli ashmaroli commented Feb 5, 2023

  • This is a 馃悰 bug fix.
  • I've added tests.
  • The test suite passes locally.

Summary

Invoking Array#[] with a non-integer argument raises no implicit conversion of String into Integer (TypeError) which is too technical and vague for end-users. Therefore, surface a more comprehensive message with additional context.

Context

Fixes #9289

TODO

Perhaps in a future pull request:

  • Let users know the error occurred via a Liquid filter or tag.

"members" => { "name" => %w(John Jane Jimmy) },
"roles" => %w(Admin Recruiter Manager),
}
assert_raises(TypeError) { @filter.where(hash, "name", "Jimmy") }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I think we want to add an assertion on the message here; this would pass without your change I think, so there's no way to know if we broke it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added an assertion.

"Error accessing object (#{liquid_data}) with given key. Expected an integer but " \
"got #{property.inspect} instead"
else
"Error accessing object with key #{property}. #{e.message}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this line is untested?

@@ -441,6 +441,12 @@ def read_liquid_attribute(liquid_data, property)
property.split(".").reduce(liquid_data) do |data, key|
data.respond_to?(:[]) && data[key]
end
rescue StandardError => e
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is StandardError too broad? Should we keep it to TypeError or only catch when we see the error message you mention in the PR description?

lib/jekyll/filters.rb Show resolved Hide resolved
@ashmaroli ashmaroli requested a review from parkr March 23, 2023 14:59
@@ -441,6 +441,14 @@ def read_liquid_attribute(liquid_data, property)
property.split(".").reduce(liquid_data) do |data, key|
data.respond_to?(:[]) && data[key]
end
rescue TypeError => e
msg = if liquid_data.is_a?(Array)
"Error accessing object (#{liquid_data}) with given key. Expected an integer but " \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Printing the whole object could be an issue. Imagine all of site.github; it would flood the terminal output with superfluous data. How would you feel about truncating the liquid_data output?

Copy link
Member Author

@ashmaroli ashmaroli Mar 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah! Good catch once again.
In theory, we could include Liquid:: StandardFilters and pass the liquid_data onto the upstream truncate filter method.
Do you think that's a good idea? Do you foresee any side-effects from this?

Update: Nevermind. I truncated directly instead.

@ashmaroli
Copy link
Member Author

@jekyllbot: merge +fix

@jekyllbot jekyllbot merged commit d03742e into jekyll:master Mar 24, 2023
9 checks passed
jekyllbot added a commit that referenced this pull request Mar 24, 2023
github-actions bot pushed a commit that referenced this pull request Mar 24, 2023
Ashwin Maroli: Handle TypeError from `where` filter gracefully (#9292)

Merge pull request 9292
@jekyll jekyll locked and limited conversation to collaborators Mar 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants