←back to thread

316 points thunderbong | 6 comments | | HN request time: 0.838s | source | bottom
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 #
adontz ◴[] 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. hambes ◴[] No.42202287[source]
It might look worse than catch, but it's much more predictable and less goto-y.
replies(2): >>42202393 #>>42208858 #
2. guappa ◴[] No.42202393[source]
goto was only bad when used to save code and jump indiscriminately. To handle errors is no problem at all.
replies(2): >>42202435 #>>42204372 #
3. froh ◴[] No.42202435[source]
yes, yes, yes! see the Linux Kernel for plenty of such good and readable uses of go-to, considered useful: "on error, jump there in the cleanup sequence ..."
4. _flux ◴[] No.42204372[source]
..as long as you don't make mistakes. I fixed enough goto bugs in Xorg when I was fixing Coverity-issues in Xorg that I can see the downsides of this easy way of error handling.
replies(1): >>42211831 #
5. int_19h ◴[] No.42208858[source]
If "catch" is goto-y (and it kinda is), then so is "defer".
6. guappa ◴[] No.42211831{3}[source]
We're comparing to go here, not with a language with proper error handling.