[zeromq-dev] zeromq, abort(), and high reliability environments

Thomas Rodgers rodgert at twrodgers.com
Wed Aug 13 00:57:34 CEST 2014


>
> I agree with you in the sense that, specifically speaking about 0mq,
> errors that can be checked synchronously (you called the function, and
> the check happens then) should return sensible error codes that
> binding authors should be responsible for checking and throwing (or
> whatever) their language specific construct to indicate that.


I tend to agree with this, but I also wonder how many of these EINVAL
results fall outside the category of options not supported by a given
socket type?  It would seem things like passing something that wasn't a
zmq_msg_t* to a function expecting it, or a socket, would be fundamental
problems for any language binding to allow in the first place.

 Having just
> got done writing way too much C++ in the last week it's almost
> refreshing.


Even with exceptions, assert(), or BOOST_ASSERT[_MSG]() are reasonable
things to do in C++ ... and probably just as refreshing :)


On Tue, Aug 12, 2014 at 5:22 PM, Michel Pelletier <
pelletier.michel at gmail.com> wrote:

> On Tue, Aug 12, 2014 at 2:42 PM, Michi Henning <michi at triodia.com> wrote:
> >
> > That seems a bit too simplistic to me. It's possible for an application
> to have some code path that is tickled only under highly unusual
> circumstances then causing invalid arguments to passed, even though the
> application is otherwise doing just fine. If the library aborts in this
> case, it sets policy in a way it isn't entitled to, IMO. Throwing an
> InvalidArgumentException instead, or returning an error in a C API is far
> better. Imagine the kernel were to apply the same strict policy and were to
> abort my process whenever I pass an invalid argument to a system call. It's
> just not the done thing.
> >
> > I believe the only time a library is entitled to abort is when it
> realizes that its own internal invariants are violated. Any other
> condition, such as resource exhaustion or pre-condition violation should be
> reported to the caller in a way that allows the caller to handle the error.
> It's up to the caller to call abort, not the library.
>
> I agree with you in the sense that, specifically speaking about 0mq,
> errors that can be checked synchronously (you called the function, and
> the check happens then) should return sensible error codes that
> binding authors should be responsible for checking and throwing (or
> whatever) their language specific construct to indicate that.
>
> However  there is a class of errors in 0mq that happen asynchronously.
> There is no caller to return a code to or thrown an exception for.
> Aborting is the only sensible option.  Unless we want to go down the
> road CUDA went, where EVERY function documentation contains the words
> "Note that this function may also return error codes from previous,
> asynchronous launches."  It's impossible to use exceptions in that
> case, because every caller would have to try to catch every possible
> exception!  Madness.
>
> Pieter's style is a bit more aggressive, but I accept it.  Having just
> got done writing way too much C++ in the last week it's almost
> refreshing.
>
> -Michel
> _______________________________________________
> 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/20140812/4d3e48e0/attachment.html>


More information about the zeromq-dev mailing list