[zeromq-dev] Newbie Bait Request: Debug "Warning" mechanism.

[Matt Weinstein]

Okay, I like the API bug approach.

How about two flavors of ZMQ_SUBS

	ZMQ_SUBS_ALL		- subscription socket, subscribed to "" ab initio
	ZMQ_SUBS_NONE	- subscription socket, no subscriptions ab initio

and deprecate ZMQ_SUBS by

#define ZMQ_SUBS ZMQ_SUBS_ALL

?

On Aug 17, 2010, at 12:22 PM, Pieter Hintjens wrote:

> On Tue, Aug 17, 2010 at 6:07 PM, Martin Lucina <mato at kotelna.sk>  
> wrote:
>
>> The 0MQ library has no business asserting on user errors. Please do  
>> not
>> introduce this behaviour.
>
> Mato, thanks for joining the discussion.
>
> IMHO the only part of this thread that really matters is whether or
> not there are valid use cases for blocking on a zombie SUB socket.
>
> The rest - whether we assert or return an error code - is
> implementation detail and I'm not going to argue it either way.  I've
> no opinion EXCEPT that the current silent thread death is not
> acceptable, it is bad design, it hits every new user, and it requires
> explanation in the Guide that should not be necessary.  I maintain
> that it's a design fault in the API and needs fixing one way or
> another.
>
> Please don't sidetrack this into a flame war over error codes vs.
> assertions.  That is besides the point.  ENOSUBS would be an fine
> option.  I've no preference for assertions except that we know from
> experience that fail-fast makes robust code when done correctly, and
> assertions are good place holders for "we need to do something about
> this when we've figured it out".
>
> Mato: could you re-read my analysis of the different use cases in this
> thread and tell me whether I'm wrong in claiming that none of the use
> cases already stated for zombie-sub-thread-death are valid?
>
> Cheers,
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev