←back to thread

314 points thunderbong | 1 comments | | HN request time: 0.199s | source
Show context
hambes ◴[] 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(7): >>42202257 #>>42202260 #>>42202261 #>>42202464 #>>42202551 #>>42202608 #>>42212195 #
gwd ◴[] 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 ◴[] 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(2): >>42202498 #>>42205775 #
1. lokar ◴[] No.42205775[source]
Or they could have fixed the error (adding the type) instead of matching the string.