On 17.06.2014, at 8:11, Pieter Hintjens <[email protected]> wrote: > Indeed... I've had this hit more than once, a zmq_setsockopt that > caused an error that wasn't being handled, with weird and expensive > results down the line. > > Kind of makes you appreciate assertions more. CZMQ does this -- if a > setsockopt fails for any reason except ETERM, it asserts. I might > propose such a patch to libzmq.
It would be nice to get a warning for non-zero return from zmq_setsockopt. But, really, the same could be said for any system call if the return value isn't handled… Asserting in response to invalid in-parameters passed by the application is not something that a library should do. After all, even with the incorrect parameter, my program may still get by and run OK, and it's not up to the library to decide whether my program should die. (For all we know, the invalid parameter may have been passed deliberately as part of a test, for example to check whether my program deals with the error return correctly.) So, at the very least, I'd allow such an assertion to be disabled by setting a macro before including the header or some such. Michi. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
