The meaning I gave is to start at the lower bound and step by one. This has the
advantage of having (n..m) and ((n.to_f)..(m.to_f)) behave the same. Another
thing we could do that have this same property is to cast bounds to integer.
This would do the right thing if there is a floating point rounding error, but I
feel it is more surprising for cases such as (1.5..8).
Note that it is not possible to create ranges with floating point boundaries
directly in Liquid at the moment. However, since there is no distinction between
Ruby and Liquid ranges, a drop can introduce such a value by returning it.
This could be used to preserve the old default of rendering
non-Liquid::Error messages or for providing default behaviour like error
reporting which could be missed if the exception renderer needed to be
specified on each render.
These errors may contain sensitive information, so is safer to
render a more vague message by default.
This is done by replacing non-Liquid::Error exceptions with a
Liquid::InternalError exception with the non-Liquid::Error accessible on
through the cause method. This also allows the template name and line
number to be attached to the template errors.
The exception_handler render option has been changed to exception_renderer
since now it should raise an exception to re-raise on a liquid rendering
error or return a string to be rendered where the error occurred.
The argument `truncate_string` is now coerced into a string to avoid
`NoMethodError`s. This is mostly for added resiliency. It is doubtful
that someone would actually intent to use a number as truncate string,
but accidentally supplying one is entirely possible.
When including a template which is not defined, the exception raised is
*undefined method `split` for nil:NilClass*
This occurs for a scenario like the following:
`{% include nil %}`
or
`{% include undefined-var %}`
Making the code raise an argument error to allow better understanding of
the include error
Currently, `truncatewords` raises a TypeError when the argument
`truncate_string` is an interger. This PR forces string coercion for any
value provided for this argument. Thus,
```ruby
assert_equal 'one two1', @filters.truncatewords("one two three", 2, 1)
```
holds true. Another option would be to raise a `Liquid::ArgumentError`.
What is preferred?
When sorting an empty array with the "sort" filter, it returns nil
instead of []. This confuses subsequent filters in the chain that
expect an array. For example, when followed by the "map" filter, it
produces an array containing one nil element: [nil].
I could special-case the nil return value, but that would be more
cumbersome than making sure "sort" always returns an array.
Add a case to the "sort" method to return [] if the array is empty,
before performing any checks on ary.first that assume a non-empty array.
There is still a danger of returning nil if the first item in the array
is nil and it is non-empty, but I'm not sure how better to handle that
case.
Apply a similar fix to sort_natural, uniq, and compact filters.
