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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
text/template: interprets nil interface{} as a map #15356
Comments
The second templates writes out "no value" with <> around it. Looks like I couldn't just say that in the initial comment. |
Seems like a bug to me. Happy to review a fix. |
Oh sorry, there seems to be something missing in this report. You mention two programs, but I only see one? Is |
The program has two template calls in it - one with 0 as an argument, and one with nil. I would expect both to return similar errors, but the second succeeds. "no value" is documented behavior for maps, but not for the nil interface. |
Maybe I'm missing something, but the linked program only has one |
Oh, sorry about that. Updated program is at http://play.golang.org/p/OaztWussVS - I did not realize that I needed to generate a new link after updating. |
This does seem like an inconsistency. I would expect both cases to return an error. But I think it has always been this way, and if we change it now, we might break existing Go programs, which we have promised we won't do. |
OK. we should probably close the issue then. Thanks! |
Thanks for the report. |
I just stumbled over this myself and I find the behavior annoying. I understand that we can not change the current behavior without breaking a promise, but could we maybe add another option for template.Option like "missingkey=error, just error!" that would trigger to handle the nil-interface case differently? I'd be happy to work on a patch for this. |
CL https://golang.org/cl/31638 mentions this issue. |
The existing implementation of text/template handles the option "missingkey=error" in an inconsitent manner: If the provided data is a nil-interface, no error is returned (despite the fact that no key can be found in it). This patch makes text/template return an error if "missingkey=error" is set and the provided data is a not a valid reflect.Value. Fixes #15356 Change-Id: Ia0a83da48652ecfaf31f18bdbd78cb21dbca1164 Reviewed-on: https://go-review.googlesource.com/31638 Reviewed-by: Rob Pike <r@golang.org> Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
Please answer these questions before submitting your issue. Thanks!
go version
)?1.6.1
go env
)?linux amd64
http://play.golang.org/p/Fk7G5f3z1q
The second template takes nil as its data, and accesses its .X field.
I would expect the second template to return an error, just like the first:
template: :1:2: executing "" at <.X>: can't evaluate field X in type int
The second template writes out "" and returns no error.
This seems to correspond to the missingkey=default behaviour, which is documented to happen for maps. I don't think the empty interface should count as a map though, so I would have expected an error instead.
I can volunteer to provide a fix if the current behaviour is recognized to be a bug.
The text was updated successfully, but these errors were encountered: