Thanks. That makes sense. In my case the only thing that raised question marks was the placing of the error (on execute vs parse)--made it fractionally harder to debug the issue I was experiencing. From there it caused me to dig deeper and come to the conclusion that it might be an issue for anyone who wanted to redefine a template as an empty string.
This is probably an edge case but I can see value in it, so I'll file an issue. On Wednesday, 22 June 2016 13:34:57 UTC-7, Rob 'Commander' Pike wrote: > > I'm not convinced there is a "why" other than "that's what happens". Feel > free to file an issue. > > -rob > > > On Wed, Jun 22, 2016 at 1:29 PM, Evan Digby <evan...@gmail.com > <javascript:>> wrote: > >> Hi Rob, >> >> Thanks! I'm using 1.6. I guess my question wasn't too clear now that I >> read it back. >> >> The question isn't why I can redefine. More specifically, my question is >> why redefining by parsing an empty string returns an error on Execute. >> >> Why can't we redefine a template as empty string? If that's expected, why >> would it not return an error when parsing and not executing? >> >> I think the "same base template" info from my original post is a red >> herring, because I imagine it's not "redefining" if they're not part of the >> same tree somehow. >> >> Thanks again, >> >> Evan >> >> On Wednesday, 22 June 2016 13:22:09 UTC-7, Rob 'Commander' Pike wrote: >>> >>> You don't say what version of Go you are running, but as of Go 1.6, >>> templates can be redefined, which supports the new 'block' feature. >>> >>> You are redefining a template, which used to be an error but is not any >>> more. >>> >>> -rob >>> >>> >>> On Wed, Jun 22, 2016 at 1:13 PM, Evan Digby <evan...@gmail.com> wrote: >>> >>>> I'm noticing that if I accidentally create a second template with the >>>> same name but no content there is no error reported when I "parse" it, but >>>> then when I attempt to execute it I do see an error: >>>> >>>> https://play.golang.org/p/Rj3433vvju >>>> >>>> Is this expected behaviour? Why wouldn't it simply return an error from >>>> the Parse call? >>>> >>>> The key is the second template must have no content. The following does >>>> not return an error on execute: >>>> >>>> https://play.golang.org/p/O5xv5rS-cg (both have content) >>>> https://play.golang.org/p/kaoVWRunrP (only the second has content) >>>> >>>> I have also noticed that this isn't an issue if they are not all based >>>> from the same template: >>>> >>>> https://play.golang.org/p/iLoHokX4uy >>>> https://play.golang.org/p/T07Z9rvfmW >>>> >>>> The inconsistency in behaviour between the examples listed is a bit >>>> confusing. If there truly is expected that the one case that does error >>>> our >>>> on execute should error out, and not the others, I believe that the error >>>> makes more sense (and could be easily caught) on the Parse call, not the >>>> execute call. >>>> >>>> Can someone provide some insight into why this might legitimately be >>>> behaving this way? >>>> >>>> Thank you! >>>> >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to golang-nuts...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
