←back to thread

Hyrum’s Law in Golang

(abenezer.org)
311 points thunderbong | 1 comments | 21 Nov 24 07:12 UTC | HN request time: 0.2s | 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(7): >>42202257 #>>42202260 #>>42202261 #>>42202464 #>>42202551 #>>42202608 #>>42212195 #
adontz ◴[21 Nov 24 08:30 UTC] No.42202261[source]▶
Honestly, this is so much worse than "catch". It's what a "catch" would look like in "C".
replies(2): >>42202287 #>>42204960 #
1. kbolino ◴[21 Nov 24 15:06 UTC] No.42204960[source]▶
The biggest difference between try-catch and error values syntactically IMO is that the former allows you to handle a specific type of error from an unspecified place and the latter allows you to handle an unspecified type of error from a specific place. So the type checking is more cumbersome with error values whereas enclosing every individual source of exceptions in its own try-catch block is more cumbersome than error values. You usually don't do that, but you usually don't type-check error values either.