[zeromq-dev] zeromq, abort(), and high reliability environments

Goswin von Brederlow goswin-v-b at web.de
Mon Aug 11 16:37:18 CEST 2014

On Mon, Aug 11, 2014 at 04:14:19PM +0200, Pieter Hintjens wrote:
> On Mon, Aug 11, 2014 at 11:33 AM, Goswin von Brederlow
> <goswin-v-b at web.de> wrote:
> > My suggestion is that if you find an assertion that gets triggered
> > then patch it out and handle the error properly and send a pull
> > request for the fix.
> Respectfully disagree. Exceptions indicate unrecoverable failure of
> one kind or another. The fix depends on the case.
> CZMQ fwiw uses exceptions to check arguments, e.g. asserts if caller
> passes NULL when not allowed. This is extremely effective. If the
> application is misusing the API then it's incapable of handling error
> codes.

If the caller passes NULL when not allowed that is a bug. So you can
assert there. That is not what I ment.

What was ment is like when a lowlevel recv() call returns EAGAIN
because some signal occured. zmq must not throw an exception there.
Signals do happen from time to time and zmq must deal with syscalls
getting interrupted (which it does).

> I've started adding more aggressive CZMQ-style exceptions to libzmq as
> well, for the options API, enabled with the --with-militant configure
> switch.
> -Pieter


PS: Personally I prever an error with EINVAL to an assertion failure
on bad arguments. Anything recoverable should not abort(). Easier for
bindings to deal with in a meaningfull way.

More information about the zeromq-dev mailing list