zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Bangert <...@groovie.org>
Subject Odd error naming… NotReadOnly when the server *is* read-only
Date Fri, 07 Sep 2012 17:07:16 GMT
As I was implementing read-only mode in the Python client based on the Java client patch, I
noticed a rather odd naming for the error you get if you send a modification command to a
read-only server...NotReadOnlyException.

Why the sudden change in error context?

For reference, here's some of the other errors that Zookeeper may return when making an API
call:
NoNode
NoAuth
BadVersion
NoChildrenForEphemerals
NodeExists
NotEmpty

So the explanation for these errors are consistent, "your API call cannot be completed because
of this state on the server". Personally, I'm a huge fan of consistency in an API, so these
are all great. But then with NotReadOnly, we have an error that is not referring to the state
of the server (that it *is* ReadOnly), but one that refers to the semantics of the API call
itself. Given all the other errors, I was really expecting the server to throw a ReadOnly
error indicating your call cannot be completed due to that state on the server (like the others).

Was there a reason for the context switch in error naming? I understand given its been merged
in for almost 2 years now that there's unlikely to be any switch to make it consistent in
context with the other errors, but it might be nice for future feature additions to try and
document or enforce better consistency in the API.

Cheers,
Ben
Mime
View raw message