←back to thread

Hyrum's Law in Golang

(abenezer.org)
107 points thunderbong | 1 comments | 21 Nov 24 07:12 UTC | HN request time: 0.211s | 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 #
gwd ◴[21 Nov 24 08:30 UTC] No.42202260[source]▶
The frustrating thing is that the error in question already is a sentinel error -- Grafana (the top-level culprit in the linked search) should be using `errors.As(&http.MaxBytesError{})` rather than doing a string compare.

The whole point of Hyrum's Law is that it doesn't matter how well you design your API: no matter what, people will depend on its behavior rather than its contract.

replies(2): >>42202472 #>>42202475 #
sssddfffdssasdf ◴[21 Nov 24 09:13 UTC] No.42202472[source]▶
But it looks like that until 3 years ago, this string comparison was the only way to do it. https://github.com/golang/go/pull/49359/files
replies(1): >>42202498 #
1. gwd ◴[21 Nov 24 09:20 UTC] No.42202498[source]▶
Good catch. So in a sense this isn't really Hyrum's Law (which would be more appropriate to things like the Sim City / Windows 3.x UAF bug described in a sibling comment); it's more like, if people need to do something, and you don't give people an explicit way to do it, they'll find an implicit way, and then you're stuck supporting whatever that happened to be.