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?
Performance is increased by doing this:
require 'benchmark'
require 'tempfile'
n = 50000
test = File.expand_path(Tempfile.new('foo'))
Benchmark.bm(20) do |x|
x.report("Regex:") do
n.times { test =~ /\A#{test}/ }
end
x.report("String#start_with?:") do
n.times { test =~ test.start_with?(test) }
end
end
Benchmark result:
user system total real
Regex: 0.440000 0.010000 0.450000 ( 0.447357)
String#start_with?: 0.000000 0.000000 0.000000 ( 0.006313)
