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 …
Either way returning values from the errno set makes a lot more sense than NIH'ing your own set.
-
-
I disagree. What they are doing is provide you with an API that does not commit to using syscalls ernnos. That makes complete sense if they want to change the implementation at some point without breaking you
-
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.