[zeromq-dev] zproxy (hopefully) improvements

[Lindley French]

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 <briank at talksum.com> 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: zeromq-dev-bounces at lists.zeromq.org [mailto:
> zeromq-dev-bounces at lists.zeromq.org] 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,  <lindleyf at gmail.com> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131205/7b6e4069/attachment.htm>