I'm not sure, if I understand all these problems - but making assert seems to throw some kind of signal - and I'm using 0MQ only by calling the dynamic library (no C code) - and whenenver the call throws an assert - my application crashes. I seem not to be able to handle these kinds of exceptions - or my dev. environment does not allow to handle such signals.
Though I handle all error (return) code in my wrappers and signal erros within my application - my application crashes simply, when an assert within the 0MQ code is thrown. I noticed this behaviour when playing with 0MQ under XP and pgm where some internal assert were fired under strange circumstances. I had to gave up using pgm, because handling these errors was not possible. Marten Am 17.06.2014 11:42, schrieb Michi Henning: > Hi Pieter, > > I'm not objecting to this as such. I agree that I need all the help I can get > from tools :-) > > It's just that calling assert in a library because an invalid argument was > passed is generally not the done thing, which is why I'm suggesting that > being able to turn that behavior off would be nice. By all means, make > asserting the default. But it would probably be nice to be able to turn this > off. > > The real cause here is the type-unsafe API for setting the option. (Yes, I > know, it's the C way of doing things…) > > Cheers, > > Michi. > > > On 17 Jun 2014, at 17:23 , Pieter Hintjens <[email protected]> wrote: > >> I think the actual evidence (I've seen two very expensive debug >> stories caused by this same behavior in the last few weeks) shows that >> returning an error in such a case is meaningless, and that a library >> asserting when passed bad arguments is measurably more robust, not >> less robust. I'm 100% sure of this. It's how CZMQ has worked since the >> start, including in the socket option classes, and no-one has ever >> flagged that as problematic. The only plausible use case is for tests, >> which is circular. >> >> However, changing existing behavior isn't allowed by our C4 >> development contract, so I was thinking of making this optional via a >> build-time option in libzmq. > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Marten Feldtmann _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
