[zeromq-dev] Fail fast

Martin Hurton hurtonm at gmail.com
Wed Jul 22 08:46:58 CEST 2009

Hi Robin,

There is a refactoring of ZeroMQ underway and among other things it
addresses this problem too. Namely, in non-fatal cases, error codes
are used rather then asserts.

- Martin

On Tue, Jul 21, 2009 at 4:09 PM, Robin Weisberg<robin.weisberg at gmail.com> wrote:
> I'm going to take a risk and put in my 2 cents on the zeromq fail fast
> implementation. I know these things can get religious and once people get
> down one path its difficult to change their minds but I feel duty bound to
> try... :)
> <2c>
> I'm OK with crashing when a library is being misused BUT things like passing
> in bad hostnames on initialization or binding to names that don't exist
> should result in an error code or exception being returned instead of
> crashing. If you ignore the error code and try to use an uninitialized
> object THEN you can crash since the developer is misusing the library. Very
> often this stuff is setup in config files or gui's and instead of giving the
> user (who may not be a developer) a chance to fix it you are crashing the
> gui or the whole process (which may be doing other things if you allow these
> things to be configured at runtime).
> Making me write code to validate all the things going into the api calls I'm
> making by doing dnslookups validating ports are open is a huge hassle and
> just doubles the work load. Its also not guaranteed to work, for example I
> can check if the zmq_server is up, but by the time I make the api call to
> connect to it went down and my app crashes instead of giving it a chance to
> reconnect gracefully, pop up an error dialog etc.
> Also I've found I have to open up the zeromq code to understand what failed,
> the asserts aren't always clear enough. If you are going to fail fast print
> a usable error message!
> I would really like this project to succeed, but I know many people will
> look at the fail fast stuff and rule zeromq out as a solution (half the
> developers where I work are having that reaction). This is doubly true in
> larger organizations for which I've worked for. Nobody will rule out a
> project for using error codes and not failing fast, because if they did
> there wouldn't be very many libraries they could use :)
> </2c>
> Robin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list