@DrGo your snippet at https://play.golang.org/p/bNEDlBZG_b doesn't compile

@odeke-em Sorry, I edited the issue to report the original error on my machine. Sorry I cannot be of more help. I noticed that if I drop the function name as in
{{range "Research Funding History"}}
I get an error instead of panic
output:
template_test.go:124: execution failed: template: test:4:8: executing "test" at <"Research Funding Hi...>: range can't iterate over Research Funding History

Also the code works flawlessly if I added the Funcs calls as in
tm, err := template.New("test").Funcs(template.FuncMap{"Block": ccv.Block}).Parse(templ3)
output:
Research
Grants

    2014/9, 2019/8, Baseline funding to the Vaccine and Drug Evaluation Centre

            Public Health Division, Manitoba Health

PASS
ok salah/CCV/template 0.006s

so closed?

No, html. Execute should not panic (see original post for details)

Please provide a complete self-contained example that reproduces the problem. You have shown us only incomplete or incorrect programs.

I cannot share my program, but I managed to replicate the error here
https://play.golang.org/p/hmwSb9Ipds

Okay the problem here is that you are ignoring the error returned that actually says the function is undefined, you just print it but you aren't actually handling it.

--- orig.go 2016-11-19 11:41:22.000000000 -0800
+++ handled.go  2016-11-19 11:41:34.000000000 -0800
@@ -3,6 +3,7 @@
 import (
    "fmt"
    "html/template"
+   "log"
    "os"
 )

@@ -34,7 +35,7 @@
    ccv := &CCV{}
    tm, err := template.New("test").Funcs(template.FuncMap{"List": ccv.List}).Parse(templ3)
    if err != nil {
-       fmt.Printf("Parsing failed: %s", err)
+       log.Fatalf("Parsing failed: %s", err)
    }
    err = tm.Execute(os.Stdout, ccv)
    if err != nil {

and particularly when handled the error returned says the function is not defined.

2016/11/19 11:40:18 Parsing failed: template: test:4: function "Block" not defined
exit status 1

I am aware of that.
html.Execute also warns correctly about function not defined, but it still seg faults.

tl;dr: you are dereferencing a nil template that already failed to parse and complained in the error returned. The panic isn't in text/template.Execute but in trying to use .Execute on a nil object

Long wind

The return signature of template.Parse is (*text.Template, error)

A common pattern for Go code return signatures, is two states of the form:

• (zero/nil objects..., non-nil error)
• (non-nil..., nil error)

which is a pattern that almost all the functions in the stdlib(except for very few if am not mistaken).

Translating that pattern thereby to template.Parse means users only have two states to check for:

• (a non-nil template, nil error)
• (nil template, non-nil error)
  so implicitly use results without worries of nil pointer deferences, after no error has been returned.

If we had the state you seem to be expecting ie

• (non-nil template, non-nil error)
  that also calls for an extra state:
• (nil template, nil error)
  then callers would also have to first check that the template itself isn't nil even when err == nil.

tmpl, err := template.New("gopher").Parse(tmplStr)
if err != nil {
   // Even if nil, you still have to check below
}

if tmpl != nil {
    // Explicitly check if tmpl is non-nil
}

so in total we'd then have 4 states to check for ie

• (zero/nil objects..., non-nil error)
• (non-nil objects..., nil error)
• (non-nil objects..., non-nil error)
• (nil objects..., nil error)

Handling the error enables us to implicitly use data in which no errors were returned but also to avoid unnecessary allocations and extra states of errors so we could do

tmpl, err := template.New("gopher").Parse(tmplStr)
if err != nil {
    // Handle it in here, this route is done
    return nil, err
}

// Home free to now use the template

Hope this makes sense.

Got it Emmanuel
Thanks,

Cool, I'll close this issue then.