←back to thread

Hyrum’s Law in Golang

(abenezer.org)
311 points thunderbong | 9 comments | 21 Nov 24 07:12 UTC | HN request time: 0s | source | bottom
Show context
adontz ◴[21 Nov 24 08:28 UTC] No.42202248[source]▶
This is a good example of "stringly typed" software. Golang designers did not want exceptions (still have them with panic/recover), but untyped errors are evil. On the other hand, how would one process typed errors without pattern matching? Because "catch" in most languages is a [rudimentary] pattern matching.

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

replies(1): >>42202266 #
KRAKRISMOTT ◴[21 Nov 24 08:30 UTC] No.42202266[source]▶
Go has typed errors, it just didn't use it in this case.
replies(7): >>42202277 #>>42202378 #>>42202617 #>>42203319 #>>42205600 #>>42206561 #>>42208318 #
1. TheDong ◴[21 Nov 24 08:55 UTC] No.42202378[source]▶
It has typed errors, except every function that returns an error returns the 'error' interface, which gives you no information on the set of errors you might have.

In other statically typed languages, you can do things like 'match err' and have the compiler tell you if you handled all the variants. In java you can `try { x } catch (SomeTypedException)` and have the compiler tell you if you missed any checked exceptions.

In go, you have to read the recursive call stack of the entire function you called to know if a certain error type is returned.

Can 'pgx.Connect' return an `io.EOF` error? Can it return a "tls: unknown certificate authority" (unexported string only error)?

The only way to know is to recursively read every line of code `pgx.Connect` calls and take note of every returned error.

In other languages, it's part of the type-signature.

Go doesn't have _useful_ typed errors since idiomatically they're type-erased into 'error' the second they're returned up from any method.

replies(2): >>42202445 #>>42206005 #
2. rocqua ◴[21 Nov 24 09:08 UTC] No.42202445[source]▶
Exceptions in Python and C are the same. The idea with these is, either you know exactly what error to expect to handle and recover it, or you just treat it as a general error and retry, drop the result, propagate the error up, or log and abort. None of those require understanding the error.

Should an unexpected error propagate from deep down in your call stack to your current call site, do you really think that error should be handled at this specific call-site?

replies(2): >>42202610 #>>42204406 #
3. adontz ◴[21 Nov 24 09:46 UTC] No.42202610[source]▶
Nope, exceptions in Python are not the same. There are a lot of standard exceptions

https://docs.python.org/3/library/exceptions.html#concrete-e...

and standard about exception type hierarchy

https://github.com/psycopg/psycopg/blob/d38cf7798b0c602ff43d...

https://peps.python.org/pep-0249/#exceptions

Also in most languages "catch Exception:" (or similar expression) is considered a bad style. People are taught to catch specific exceptions. Nothing like that happens in Go.

replies(2): >>42203226 #>>42206411 #
4. vlovich123 ◴[21 Nov 24 11:29 UTC] No.42203226{3}[source]▶
C also doesn’t have exceptions and C++ similarly can distinguish between exception types (unless you just throws a generic std::exception everywhere).
5. TheDong ◴[21 Nov 24 14:05 UTC] No.42204406[source]▶
Yes, python and C also do not have properly statically typed errors.

In python, well, python's a dynamically typed language so of course it doesn't have statically typed exceptions.

"a better type system than C" is a really low bar.

Go should be held to a higher bar than that.

6. inlined ◴[21 Nov 24 16:35 UTC] No.42206005[source]▶
You actually should never return a specific error pointer because you can eventually break nil checks. I caused a production outage because interfaces are tuples of type and pointer and the literal nil turns to [nil, nil] when getting passed to a comparator whereas your struct return value will be [nil, *Type]
replies(1): >>42208350 #
7. rocqua ◴[21 Nov 24 17:15 UTC] No.42206411{3}[source]▶
Sure, there is a hierarchy. But the hierarchy is open. You still need to recurse down the entire call stack to figure out which exceptions might be raised.
8. stouset ◴[21 Nov 24 20:34 UTC] No.42208350[source]▶
It's really hard to reconcile behavior like this with people's seemingly unshakeable love for golang's error handling.
replies(1): >>42210600 #
9. TheDong ◴[22 Nov 24 02:21 UTC] No.42210600{3}[source]▶
People who rave about Go's error handling, in my experience, are people who haven't used rust or haskell, and instead have experience with javascript, python, and/or C.

https://paulgraham.com/avg.html