A great example on what's wrong with golang error handling. Pushing meaningful ERRNO value into a meaningless string, that cant't be specifically matched on. What if I actually expect EINVAL? How can I ensure it was returned - by string matching? UGLY.https://github.com/nathanjsweet/ebpf/blob/master/syscalls.go#L128 …
I still think it makes more sense to use a well-known set of error codes than invent your own. They're not "syscall" error codes. They're posix ones.
-
-
this comes down to whether this package is a thin wrapper or not (it probably is). E.g. if I would, at some point, implement an API via a network filesystem, any user depending on errnos I return would break. If I want to keep that option open, I can't make errnos part of my API
-
For a not library it probably makes sens e to expose error numbers, yes. But it's still an API problem, not a language problem; the developers of *that package* chose to not make errnos part of their API.
-
*a bpf library - typing on phones sucks :)
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.