Why is this one error promoted to a variable but no others?

It was our only typed error (error we logged, vs propagating up from iptables).

----- Original Message -----

@@ -319,38 +319,43 @@ type Proxier struct {
hostIP net.IP
}

+var (

• ErrProxyOnLocalhost = fmt.Errorf("cannot proxy on localhost")

Why is this one error promoted to a variable but no others?

---

Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/pull/8269/files#r30357599

Who is "we" ?

• glog.Errorf("Failed to select a host interface: %v", err)
• glog.Errorf("Failed to initialize iptables: %v", err)
• glog.Errorf("Failed to flush iptables: %v", err)

Why is this one more important? does someone need to test whether an error they receive is the "not on localhost" error? Who/where?

We was "the proxier". I wanted to check on ErrProxyOnLocalhost since it's doing argument validation and we want to give a very specific message to users. ProxyLocked I wanted to test on. Initialize and test on were generic errors - yeah it failed, we can't start the proxy because of some arbitrary iptables craziness.

Basically the difference between http 422 and 404 - 422 means something very specific, 404 could mean anything. The ProxyOnLocalhost was validation, the others were "we can't start because of 🤷")

But nobody uses this yet...

Shouldn't you pre-validate that, then, rather than surfacing it from the depths of the app? It's a pretty specific error to catch, you might as well check it yourself.

So then we have to expose a method to check it. Any everyone has to check it the same way. And everyone needs a consistent message. Seems like you're arguing against people returning known error types from functions? If I set up a TLS config and get back a TLS typed error (this is invalid) isn't that reasonable?

----- Original Message -----

@@ -319,38 +319,43 @@ type Proxier struct {
hostIP net.IP
}

+var (

• ErrProxyOnLocalhost = fmt.Errorf("cannot proxy on localhost")

Shouldn't you pre-validate that, then, rather than surfacing it from the
depths of the app? It's a pretty specific error to catch, you might as well
check it yourself.

---

Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/pull/8269/files#r30387927

Typed errors are fine (though it's not my favorite aspect of Go, whatevs).
My point was to grok why some errors matter more than others.

On Fri, May 15, 2015 at 7:32 AM, Clayton Coleman notifications@github.com
wrote:

In pkg/proxy/proxier.go
#8269 (comment)
:

@@ -319,38 +319,43 @@ type Proxier struct {
hostIP net.IP
}

+var (

• ErrProxyOnLocalhost = fmt.Errorf("cannot proxy on localhost")

So then we have to expose a method to check it. Any everyone has to check
it the same way. And everyone needs a consistent message. Seems like you're
arguing against people returning known error types from functions? If I set
up a TLS config and get back a TLS typed error (this is invalid) isn't that
reasonable?
… <#14d57fde9d752fa5_>
----- Original Message -----

@@ -319,38 +319,43 @@ type Proxier struct { > hostIP net.IP > } > >
+var ( > + ErrProxyOnLocalhost = fmt.Errorf("cannot proxy on localhost")
Shouldn't you pre-validate that, then, rather than surfacing it from the
depths of the app? It's a pretty specific error to catch, you might as well
check it yourself. --- Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/pull/8269/files#r30387927

—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/8269/files#r30412964
.

Will add comments to the intended use (every consumer of NewProxier having the same validation error).

On May 15, 2015, at 12:05 PM, Tim Hockin notifications@github.com wrote:

In pkg/proxy/proxier.go:

@@ -319,38 +319,43 @@ type Proxier struct {
hostIP net.IP
}

+var (

• ErrProxyOnLocalhost = fmt.Errorf("cannot proxy on localhost")
  Typed errors are fine (though it's not my favorite aspect of Go, whatevs). My point was to grok why some errors matter more than others.
  …
  —
  Reply to this email directly or view it on GitHub.

it's OK. I get it, I just wanted to probe you for what distinguishes.
This is LGTM

On Fri, May 15, 2015 at 9:29 AM, Clayton Coleman notifications@github.com
wrote:

In pkg/proxy/proxier.go
#8269 (comment)
:

@@ -319,38 +319,43 @@ type Proxier struct {
hostIP net.IP
}

+var (

• ErrProxyOnLocalhost = fmt.Errorf("cannot proxy on localhost")

Will add comments to the intended use (every consumer of NewProxier having
the same validation error).
… <#14d5868689f8dd5c_>
On May 15, 2015, at 12:05 PM, Tim Hockin notifications@github.com
wrote: In pkg/proxy/proxier.go: > @@ -319,38 +319,43 @@ type Proxier struct
{ > hostIP net.IP > } > > +var ( > + ErrProxyOnLocalhost =
fmt.Errorf("cannot proxy on localhost") Typed errors are fine (though it's
not my favorite aspect of Go, whatevs). My point was to grok why some
errors matter more than others. … — Reply to this email directly or view it
on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/8269/files#r30423449
.