[zeromq-dev] zeromq, abort(), and high reliability environments
rodgert at twrodgers.com
Wed Aug 13 00:13:41 CEST 2014
> 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.
It seems optimistic to to expect that the application will be doing fine
after going down some poorly tested code path "tickled only under highly
On Tue, Aug 12, 2014 at 4:49 PM, Thomas Rodgers <rodgert at twrodgers.com>
> On Tue, Aug 12, 2014 at 4:42 PM, Michi Henning <michi at triodia.com> wrote:
>> > Yet I'll repeat my assertion that if an
>> > application or binding is incompetent enough to pass garbage
>> > arguments, then it cannot be competent enough to check errors
>> > properly.
>> 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.
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev