<div dir="ltr"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 12, 2014 at 4:42 PM, Michi Henning <span dir="ltr"><<a href="mailto:michi@triodia.com" target="_blank">michi@triodia.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">><br>
> Yet I'll repeat my assertion that if an<br>
> application or binding is incompetent enough to pass garbage<br>
> arguments, then it cannot be competent enough to check errors<br>
> properly.<br>
<br>
</div>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.<br>

<br>
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.<br>

<span class="HOEnZb"><font color="#888888"><br>
Michi.<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
zeromq-dev mailing list<br>
<a href="mailto:zeromq-dev@lists.zeromq.org">zeromq-dev@lists.zeromq.org</a><br>
<a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
</div></div></blockquote></div><br></div>