Same. - Bruce Sent from my iPhone > On Sep 2, 2014, at 1:06 PM, Matt Howlett <matt.howlett@xxxxxxxxx> wrote: > > > I agree completely... the way abort is used in nanomsg prevents me from using > it in scenarios I otherwise would like to. > > >> On Tue, Sep 2, 2014 at 3:56 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote: >> I'd argue that's a bug. And yet, I see lots of these things in the >> underlying code now that I look. :-( >> >> Libraries should only ever abort() in the event that the library developer >> created a bug -- and *every* case where the library abort()'s or fails an >> assertion should be treated as a high priority bug. >> >> >>> On Mon, Sep 1, 2014 at 10:49 PM, Jihyun Yu <yjh0502@xxxxxxxxx> wrote: >>> Hi, >>> >>> It seems that nanomsg aborts on recoverable error. For example >>> following code fails with abort(); >>> >>> == >>> #include <nanomsg/nn.h> >>> #include <nanomsg/pubsub.h> >>> >>> int main(void) { >>> int socket = nn_socket(AF_SP, NN_PUB); >>> if(socket < 0) return socket; >>> int tp1 = nn_bind(socket, "tcp://*:11234"); >>> if(tp1 < 0) return tp1; >>> int tp2 = nn_bind(socket, "tcp://*:11234"); >>> if(tp2 < 0) return tp2; >>> >>> return 0; >>> } >>> == >>> >>> Here's an output >>> >>> == >>> Address already in use [98] (src/transports/tcp/btcp.c:378) >>> /bin/bash: line 1: 22624 Aborted ./a.out >>> == >>> >>> I'm writing Erlang binding of nanomsg[1], and calling abort() inside >>> library functions is not acceptable in Erlang. Is the design >>> intentional? >>> >>> >>> [1] https://github.com/yjh0502/nanomsg >