You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Normally, when I use custom functions inside an html/template template, errors returned
by my custom functions will be returned to the caller of template.Execute. Unfortunately
this stops working when you clone templates. It will then panic on any error with a
"slice bounds out of range".
What steps will reproduce the problem?
See: http://play.golang.org/p/dvleW7dxE9
What is the expected output?
template: :1:2: executing "" at <myFunc>: error calling myFunc: My error!
What do you see instead?
panic: runtime error: slice bounds out of range [recovered]
panic: runtime error: slice bounds out of range
Which compiler are you using (5g, 6g, 8g, gccgo)?
- reproducible in go playground -
Which operating system are you using?
- reproducible in go playground -
Which version are you using? (run 'go version')
- reproducible in go playground -
Please provide any additional information below.
The text was updated successfully, but these errors were encountered:
It turns out that all errors that occur during template execution suffer from this bug.
For example, if you add an argument to the myFunc function call in the playground
example you also get the same problem:
const tmplString = `{{myFunc "arg1"}}`
I am currently considering, as a partial workaround, to create wrappers for all custom
functions that start panicking on any returned errors. For example, if you rewrite
myFunc in the go playground example as follows, then the error is returned:
func myFunc() (string, error) {
panic(fmt.Errorf("My error!"))
}
Anyone a better idea? This works for custom functions, but of course not for errors that
occur in the template itself.
The problem is that text/template/parse's Tree.text wasn't getting copied during the
clone. Unfortunately, I don't see any way to fix this without adding to the public API.
Proposed fix in https://golang.org/cl/12420044
by pavadeli:
The text was updated successfully, but these errors were encountered: