[zeromq-dev] Questions about Coding Style

[Gary Wright]

On Feb 12, 2012, at 1:39 AM, john skaller wrote:
> 
> For example, in the C binding, a C++ "null pointer exception" thrown could be
> caught and translated into something else, eg EINVAL return code.
> It seems risky: ZMQ specifies in the Coding Style that no exceptions should
> be thrown. This probably means the code doesn't try to be exception safe.
> In turn that means returning an error code is risky, even for a language binding.
> 
> Gary, you have an actual use case?

Note sure what you mean by 'use' case.  As a general principle I don't think
a library should abort or otherwise terminate a process unless there is no safe
way for the error to be reported up the call stack. Errors should be reported
back to the client code in some reasonable, hopefully idiomatic way.

For example, in Ruby, it is common for invalid arguments to be flagged by
raising the ArgumentError exception (wrong number of arguments, invalid
argument, etc.)

I do tend to agree with the idea that if the library client code violates
a pre-condition then all bets are off but I also realize that detecting 
those violations in the library can be helpful during debugging and can
prevent more obscure problems from occurring later in execution.

In the ZMQ context this is all complicated by the fact that the core code
is written in C++, while most language bindings (I believe) tend to build
upon a C wrapper for the C++ core.  So you've something like:

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.

Gary Wright