On Mon, Aug 11, 2014 at 04:37:18PM +0200, Goswin von Brederlow wrote: > 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-...@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.
Must not throw an assertion there. An exception in the highlevel bindings (if the language has any) could be ok. That's a matter of taste and language style. > 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 > > MfG > Goswin > > 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. > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
