←back to thread

Hyrum's Law in Golang

(abenezer.org)
107 points thunderbong | 5 comments | 21 Nov 24 07:12 UTC | HN request time: 1.071s | source
Show context
hambes ◴[21 Nov 24 08:20 UTC] No.42202204[source]▶
Solution to the specifically mentioned problem: Don't use string-based errors, use sentinel errors [1].

More generally: Don't produce code where consumers of your API are the least bit inclined to rely on non-technical strings. Instead use first-level language constructs like predefined error values, types or even constants that contain the non-technical string so that API consumers can compare the return value againnst the constant instead of hard-coding the contained string themselves.

Hyrum's Law is definitely a thing, but its effects can be mitigated.

[1]: https://thomas-guettler.de/go/wrapping-and-sentinel-errors

replies(6): >>42202257 #>>42202260 #>>42202261 #>>42202464 #>>42202551 #>>42202608 #
1. Svip ◴[21 Nov 24 08:29 UTC] No.42202257[source]▶
In your example, the onus is on the consumer not the provider. I could still be writing code that checks if `err.String() == "no more tea available."`. I agree, I shouldn't do that, but nothing is preventing me from doing that. Additionally, errors.Is is a relatively recent addition to Go, so by the time people would check for errors like this, it was just easier to check the literal string. But as an API provider in Go, you cannot prevent your consumers from checking the return values of .String().
replies(1): >>42202284 #
2. hambes ◴[21 Nov 24 08:35 UTC] No.42202284[source]▶
Unfortunately true. The Go maintainers might not agree with me on this, but I think in this case consumers have to learn the hard way. Go tries to always be backwards compatible, but I don't think that trying to be backwards compatible with incorrect usage is ever the right choice.
replies(1): >>42202783 #
3. LudwigNagasena ◴[21 Nov 24 10:18 UTC] No.42202783[source]▶
So the people who decided to make a stringly type error with `errors.New("http: request body too large")` and make you suffer, now can remove a stringly typed error and make you suffer even more? What would the lesson be? What would consumers learn?
replies(1): >>42203648 #
4. hambes ◴[21 Nov 24 12:28 UTC] No.42203648{3}[source]▶
I don't understand your point. The lesson is "don't rely on magic strings, instead rely on exported and documented constants, otherwise your code might break".
replies(1): >>42203983 #
5. LudwigNagasena ◴[21 Nov 24 13:11 UTC] No.42203983{4}[source]▶
My point is that a few years ago there was no exported and document constant. The lesson should be "provide sensible tools, otherwise your consumers will have to rely on implementation details for the most basic expected stuff".