[zeromq-dev] Questions about Coding Style

[Gary Wright]

On Feb 12, 2012, at 4:40 PM, Mikko Koppanen wrote:

> On Sun, Feb 12, 2012 at 9:28 PM, Gary Wright <at2002+zmq at me.com> wrote:
>> ruby client code => ruby binding => libzmq C binding => C++ core
>> 
>> So I would just apply the principle described above to each interface.
>> 
>> The C++ code should use error codes/exceptions according to C++ idioms.
>> The libzmq C interface should translate C++ exceptions into error codes.
>> A Ruby binding, for example, should translate some errors back into exceptions.
> 
> Hello,
> 
> I don't necessarily agree that the library code should take care of
> validating every argument passed to it.

I don't think I actually said that. In fact I agreed with the fact that
violation of pre-conditions is a problem with the caller, not the callee.
I was trying to acknowledge both sides of the argument.

> In your example the ruby binding should take care of the sanity of the
> arguments passed to lower level or the ruby binding can be built on
> top of czmq, which does more validation.

I don't disagree with this in principle, but libzmq, for example, isn't
*only* used by other libraries (i.e., language binding).  It is possible
to use it directly and so we find ourself having the exact same
decision to be made at that level (i.e. check the arguments or not).

Perhaps the solution is to have two interfaces to the library. A
'paranoid' interface that reports errors as much as possible and a
'go wild' interface that simply assumes that everything has been
checked.  The 'paranoid' interface can simply wrap the 'go wild'
interface and clients can pick and choose the interface that meets
their needs?

> Adding more validation and cruft on the critical path means additional
> CPU cycles wasted, which is not desirable in all cases. In my opinion
> the raw library can and should assume that sane arguments are being
> passed in and the higher level interfaces (czmq for example) can and
> should do the validation on top of it if necessary.

I sympathize with that point of view and perhaps czmq is the 'paranoid'
library in this case?

I think this is an interesting discussion, but it is also an abstract
one about API design principles. I don't pretend to have an informed
opinion on how this might best be applied to the ZMQ code base. I mainly
jumped in to express some concern with the idea that assert/abort/exit
is anything other than absolutely last course of action in the
context of library code.

Gary Wright