We do have a lot of functions that bubble up standard error numbers -- in general callers of these functions have to accommodate the possibility of any error code (including errors they don't understand). I notice that ::mount is a bit unusual in additionally having some explicit 'magic' return codes to indicate which stage of init failed. A pull request to document the magic -1001, -1002 etc returns from that function would be welcome, it might not be useful to try and enumerate all possible error numbers for all API calls though -- it could be hard to prove that the list was comprehensive, and callers should always handle unexpected codes too. Cheers, John On Fri, Oct 10, 2014 at 5:22 PM, Barclay Jameson <almightybeeij@xxxxxxxxx> wrote: > When reading code for libcephfs.cc (giant branch) it wasn't apparent > to me for the lines 95 and lines 101 what the return values was > expected from the function calls init and mount other than 0. > > It was only after tracing a bit of code did I see that error code such > as: -ENOENT and -EEXIST could be returned as well. > > It would be awesome if comments were added for these functions to show > what the expected return values are going to be for these functions. > > Thanks, > > almightybeeij > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
