[zeromq-dev] Fail fast

[Robin Weisberg]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090721/84c9fe19/attachment.htm>