On 2 May 2011, at 12:54 , Angelo van der Sijpt wrote:
> I took a quick look at the rest of the PersistenceManager API, and the first
> thing I noticed is that it contains Hector API class references.
>
> However, getting to your question: in general I feel you should only throw a
> checked exception if something has really gone wrong that can be usefully
> recovered from, and throw unchecked exceptions for (a) violated
> preconditions, since those won't occur for well-behaved code, and (b) real
> disasters. Applying those rules, we get to
> 1. throw a NullPointerException if any of the required parameters is null,
> while you state in Javadoc that it cannot be. This is a public API, so you
> should be defensive here, and fail quickly.
> 2. idem.
Agreed.
> 3, 4 and 5 are roughly in the same ballpark: I think they are part of the
> normal flow of your application, and you should be prepared to handle the
> absence of certain data; I would return null, and not throw an exception,
> since there is no reasonable way to recover from this, because we don't know
> exactly what is going on. I would, however, log this as a warning.
In general, I would not return "null" and make it into a magic value. That is,
unless you can normally never get a null value back. So it depends. You could
even decide to throw an illegal argument exception, but a more specific
exception would be an option as well.
> 6. is a hard one, and depends on how 'smart' you want your API to be. If you
> state 'if it's not the correct type, you're out of luck', I think an
> exception would be in order; perhaps even let the ClassCastException bubble
> up. (You can of course make the API smarter, trying to coerce the value you
> get into the requested type, perhaps even by parsing strings to numbers, but
> that is outside the scope of this question. Also, I think Cassandra would
> disapprove of this.)
I would not make my API too smart in this case, unless you can also make the
corresponding setValue() as smart. In general though, I'd keep the API as
simple and non-redundant as possible. Let clients or utility code on top of
that try to be smart.
> 7. Apparently, Hector uses the exception mechanism a bit differently than we
> do. I would not let myself be constrained by that, but rather use the
> mechanism I want.
Agreed.
> As for the consistency: that is the way Cassandra works, and represents the
> tradeoffs that have been made to get the scalability they require. When using
> the Amdatu Cassandra service, you should be very well aware of the 'eventual
> consistency' that Cassandra has. Therefore, I don't think our API should try
> to hide that, and give a 'consistent feel': we would by lying to our users
> that way. As for the usefulness of 'exists', I have no opinion either way.
Agreed with the "not trying to hide this" part. Furthermore, any service can
fail at any point in time and as a client you should always be aware of that.
The exists type methods make sense to me, it allows you to get some metadata
about what's in Cassandra. They should not be use in constructions like:
if (exists(A)) {
setValue(A, B);
}
Greetings, Marcel
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers
