On Mon, Dec 13, 2021 at 6:15 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Mon, Dec 13, 2021 at 3:10 PM Grant Seltzer Richman
> <grantseltzer@xxxxxxxxx> wrote:
> >
> > I'm using libbpf and want to make sure I'm properly handling errors.
> >
> > I see that some functions (such as `bpf_map_batch_common`) return
> > error codes using `libbpf_err_errno()`. My understanding is that since
> > libbpf_err_errno() returns -errno, these function calls can just be
> > followed by checking the returned error code.
> >
> > Some functions (such as `bpf_map__pin`) return `libbpf_err(int ret)`
> > which sets errno and returns the error code. In this case, does errno
> > even need to be checked?
> >
>
> No it doesn't, checking directly returned error is enough. We set
> errno always for consistency with APIs that return pointers (like
> bpf_object__open_file(), for example). For the latter, on error NULL
> is going to be returned (in libbpf 1.0 mode), so the only way to get
> details about what failed is through errno.
>
> so doing:
>
> if (some_libbpf_api_with_error_return(...)) {
> /* errno contains error */
> }
>
> is the same as
>
> err = some_libbpf_api_with_error_return(...);
> if (err < 0) {
>
> }
>
>
> But you only can use:
>
> ptr = some_libbpf_api_returning_ptr(...);
> if (!ptr) { /* errno has error */ }
>
>
> I plan to remove libbpf_get_error() in libbpf 1.0, btw. The pattern
> above will be the only one that could be used.
Thanks for the info! I think I have a couple instances of usage wrong
in libbpfgo. I will submit a patch to document this accordingly.
>
>
> > Why the inconsistency? I'd like to document this, so anything else
> > that you can add on error handling in libbpf is welcome. That includes
> > example usage.
> >
> > Thanks!
