The thing about shared libraries is that they can turn logic errors into runtime errors. Therefore, you need to treat them as such, or else impose a minimum requirement on the library version and generate a runtime error at load time if you don't have one that's good enough.
On Thu, Dec 5, 2013 at 2:07 PM, AJ Lewis <[email protected]> wrote: > Who's only using static linkage? I'm using shared objects and DLLs with > zeromq and czmq exclusively. > > AJ > > On Thu, Dec 05, 2013 at 12:12:09PM -0500, Lindley French wrote: > > This is mostly an academic question so long as libzmq is statically > linked. > > If it were ever dynamically linked, it would be much more important to > get > > this right. > > > > The distinction is similar to what the C++ standard library classifies > as a > > "logic error" vs a "runtime error". A logic error means, "Hey, you, > > programmer. Yes, you. You did something bad. It's your fault I crashed." > I > > have no particular problem using asserts to protect against this > (although > > if you are literally calling "assert(condition)", be aware these calls > > disappear when NDEBUG is defined), or in general crashing immediately at > > this point. Bugs are easier to pin down that way. > > > > A "runtime error" means "The code the programmer wrote *could* have > worked > > in some cases, but it didn't work this time. Would you like to try > > something else?" An example might be trying to contact a server which is > > currently down. Asserts, exits, etc are incredibly inappropriate in these > > sorts of cases. Use an error code (or an exception in C++), so the > program > > has a chance to recover from the problem. > > > > In the scenario you describe, it sounds like calling those methods is a > > logic error. My first impression is that option #1 is the best, on the > > theory that errors should be caught as soon as possible, and option 1 > > allows you to catch this error at compile time or link time, instead of > > waiting for runtime. On the other hand, linker errors can be notoriously > > difficult to diagnose, so an informative runtime error can sometimes be > > preferable. > > > > > > On Thu, Dec 5, 2013 at 11:32 AM, Brian Knox <[email protected]> wrote: > > > > > To go into more detail: > > > > > > Calling zproxy_pause, zproxy_resume, and zproxy_terminate on libzmq > 2.2 -> > > > 4.0 does not do anything, as zmq_proxy_steerable was added after 4.0. > > > > > > I mulled over three approaches to address this: > > > > > > 1) Have an #if ZMQ_VERSION macro that simply removed those methods if > czmq > > > is built against a libzmq does does not have zmq_proxy_steerable > > > 2) Throw an assert if those methods are called when czmq is built > against > > > a libzmq that does not have zmq_proxy_steerable > > > 3) Do nothing, and return a -1 when those methods are called when czmq > is > > > built against a libzmq that does not have zmq_proxy_steerable > > > > > > My gut was leaning towards going with option #2, but I talked myself > into > > > going with option #3 rationalizing that it was "more backwards > compatible". > > > > > > However, since the calls won't actually do anything except return an > error > > > code - perhaps exploding via an assert is a more assertive > communication > > > that the API user has tried to do something that can not work. > Thinking > > > about it, I can't think of a scenario where I would want my code to > call > > > these functions when czmq is built against a libzmq that can't support > them. > > > > > > Lindley and Pieter - thank you both for your feedback! > > > > > > Brian > > > > > > -----Original Message----- > > > From: [email protected] [mailto: > > > [email protected]] On Behalf Of Pieter Hintjens > > > Sent: Thursday, December 05, 2013 11:12 AM > > > To: ZeroMQ development list > > > Subject: Re: [zeromq-dev] zproxy (hopefully) improvements > > > > > > On Thu, Dec 5, 2013 at 2:52 PM, <[email protected]> wrote: > > > > > > > I'm of the opinion that asserts should only be used to signal an > > > internal problem with the library. Any external interface should > instead > > > use error codes if the input is detectably bad. So the question > becomes, if > > > you build against a lower version of ZMQ, is that an error or does it > just > > > reduce your capabilities? Can you require a minimum version, and check > this > > > at init time? > > > > > > CZMQ already uses very extensive asserts to catch bad arguments. > > > Building against a lower version of libzmq is fine. Trying to use > > > non-existent features is bogus, IMO. > > > > > > -Pieter > > > _______________________________________________ > > > zeromq-dev mailing list > > > [email protected] > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > > > zeromq-dev mailing list > > > [email protected] > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > -- > AJ Lewis > Software Engineer > Quantum Corporation > > Work: 651 688-4346 > email: [email protected] > > ---------------------------------------------------------------------- > The information contained in this transmission may be confidential. Any > disclosure, copying, or further distribution of confidential information is > not permitted unless such privilege is explicitly granted in writing by > Quantum. Quantum reserves the right to have electronic communications, > including email and attachments, sent across its networks filtered through > anti virus and spam software programs and retain such messages in order to > comply with applicable data security and retention requirements. Quantum is > not responsible for the proper and complete transmission of the substance > of this communication or for any delay in its receipt. > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
