socket_t class included in C++ bindings throws exceptions in destructor
Description
Environment
Windows and Linux
Activity

Dorin Ciobanu January 18, 2012 at 2:08 PM
Ok. Thanks for such a quick response!

Martin Sustrik January 18, 2012 at 2:06 PM
The only possible failure here is failure of zmq_close() function. The documentation mentions only a single possible error:
ENOTSOCK
The provided socket was invalid.
I think we can safely assert on that condition.

Dorin Ciobanu January 18, 2012 at 2:01 PM
... that being said, I never actually encountered a failed close. The only reason I raised the issue, is that design-wise, using shared_ptr with a class that can throw an exception in destructor is bad. So assert would suffice too.

Dorin Ciobanu January 18, 2012 at 1:59 PM
I'd use assert in cases where the error can not be handled and/or can lead to unexpected behavior.
In cases like this one, where the application closes/destroys the socket for cleanup reasons, there is no unexpected behavior possible. Crashing the application for this reason would be an overkill IMHO.
I'd prefer the destructor to catch error_t. And if I want to make sure that socket closes correctly, I can just try ... socket->close(...) ... catch.

Martin Sustrik January 18, 2012 at 1:38 PM
What about replacing the code in socket_t::close() function with something like this:
int rc = zmq_close (ptr);
assert (rc == 0);
socket_t::~socket_t calls socket_t::close, which can throw error_t exception.
It becomes an issue when smart pointers are used, and the exact moment the destructor will be called is unknown.
Possible solution would be to catch all exception in destructor.