[zeromq-dev] Fail fast

[Robin Weisberg]

Thats very good news, thanks. Is there an API I can look at?

The link in this email:
http://lists.zeromq.org/pipermail/zeromq-dev/2009-June/000865.html
doesn't seem to work. I checked out trunk and zsock_refactoring and it isn't
clear to me where I should be looking.

Also I'd be interested if you have a rough timeline for support of multicast
via java on windows and c++ on linux. If any of it is working in svn I might
check it out. Is there a different JIRA for this project? I couldn't find
any releases related to it on http://jira.fastmq.org/.

Thanks!
Robin


On Wed, Jul 22, 2009 at 2:46 AM, Martin Hurton <hurtonm at gmail.com> wrote:

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