I would but I can't access github from my work. Talking it through is my best option in the short term.
> On Jan 13, 2014, at 1:06 PM, Pieter Hintjens <[email protected]> wrote: > > Handling EINTR with exceptions seems messy. The right way to improve > the quality of code sent via pull requests is simply to patch it into > shape or delete it if it's offensive (upfront code reviews tend to > just introduce friction). > >> On Mon, Jan 13, 2014 at 6:45 PM, Lindley French <[email protected]> wrote: >> My zmqpp code has ended up completely littered with clauses like: >> >> bool gotit = false; >> try >> { >> gotit = ts.receive(clientId_str,msgin); >> } >> catch (zmqpp::zmq_internal_exception e) >> { >> if (e.zmq_error() != EINTR) >> { >> throw; >> } >> } >> >> This is messy, and clearly not ideal because a class type with "internal" in >> the name shouldn't be necessary for the library user. >> >> So let's think for a minute. The purpose of EINTR is to ensure blocking >> calls can't prevent signal handling from working properly. It isn't really >> an exceptional condition, so is an exception the appropriate way to handle >> it? (I'm of the opinion that, unlike Java, exceptions in C++ should normally >> be reserved for things going seriously wrong.) >> >> The two places this occurs are poller::poll() and socket::receive(). Both of >> these already return bool. Perhaps we can simply return false in the event >> if EINTR, instead of throwing? At the very least, this makes sense for the >> non-blocking version of receive(). >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
