Question about `close(2)` in destructor

[robertdfrench]

Hello!

I was attempting to roll my own socket library before I discovered sockpp (which is excellent, btw). One thing that stumped me in my own design was how to handle the case where close(2) is called from within a destructor, but returns an error.

I see below that you opted not to handle a bad response from close: https://github.com/fpagliughi/sockpp/blob/e5466faa9fffbe27e3b5f4921a7e153f26ebf00c/src/socket.cpp#L262

Do you think such a response is unlikely, or not applicable with this kind of file descriptor? Or do you expect that users would have a way to know within their application that close failed? The situation described in the (macOS) man page is that close could return an error if there were unreported problems with the previous write(2), but I have not been able to trigger that in practice.

Thank you for clarifying, I was super stumped by this one.

[fpagliughi]

Yes, I just chose to ignore the return value from close() in the destructor for a few reasons. First, as you guessed, errors from close() are pretty rare. We could check and cache a last error, but then, since the object is disappearing, there would be no way to check. And throwing an exception from the destructor would be a total mess.

But you do bring up a good point. If the app was really interested in checking the return value of close(), then it should call the function manually, in which case the destructor would revert to a no-op.

But the close() function isn't returning a value or caching the errno on error!

I will fix that right away.