Go at Google: Language Design in the Service of Software Engineering

Re:Go at Google: Language Design in the Service of Software ... by burntsushi on Wednesday December 05, 2012 @09:41PM (#4879994)

You have been mislead. Better advice for panicing in Go is to panic in truly exceptional or unrecoverable circumstances. For example, a programmer error (violating the terms of a function contract) is a perfectly reasonable justification for panicing across package boundaries.

The Go standard library:

    grep -nrHIF 'panic(' /opt/go/src/pkg/* | wc -l
    632

Note that this is somewhat inflated with a lot of `panic("unreachable")` calls. They are a symptom of the standard Go Compiler requiring a `return` on every code path of a function that returns at least one value. A `panic(...)` relaxes this requirement. In this case, a panic arising would indicate a bug in the package. Which is another good reason to panic across package boundaries :-)

[ Parent | on HN ]

Re:Go at Google: Language Design in the Service of Software ... by frou_dh on Thursday December 06, 2012 @12:30PM (#4882674)

Alright, that makes more sense to me.

Do you know if they intend to fix the need for phoney code paths? It seems odd that a language with nice support for first class functions and closures can't acknowledge when "if ... else ..." has complete flow coverage.

[ Parent | on HN ]

Re:Go at Google: Language Design in the Service of Software ... by burntsushi on Thursday December 06, 2012 @03:00PM (#4883521)

> Do you know if they intend to fix the need for phoney code paths?

It's a purposeful restriction imposed by the Go compiler, but not by the Go language specification.

And I think the idea is to encourage explicitness, and force cases like these:

    if cond {
        return ...
    } else {
        return ...
    }

Into a simpler:

    if cond {
        return ...
    }
    return ...

Reasonable people can disagree over whether this is a Good Thing.

[ Parent | on HN ]