Hi All, With the individual releases of subprojects, we are trying to 'finalize' some of the APIs exposed by these subprojects. One example of such API is the Cassandra Persistence Manager, which provides a persistence API for Cassandra. While improving and extending the javadoc describing this API, I realized that it still lacks a consistent approach in handling all kind of errors. So I want to come up with some guidelines on when a method should throw a checked exception, when it should throw an unchecked exception and when it should return null. By example I would like to discuss this for the following method, as it covers most use cases:
<T> T getValue(String columnFamily, String rowKey, String superColumn, String column, Class<T> clazz); This method returns the value from a column and/or super column for the specified row key in the specified column family. Now there are many reasons why this value cannot be returned, being; - 1. Null input arguments. The specified column family and row key must not be null. - 2. Invalid input arguments. If the specified column family is of type 'super', both superColumn and column must not be null. In case the specified column family if of type 'standard' however, superColumn must be null and column must not be null. - 3. Inexistent columnFamily. The specified column family might not exist (i.e. deleted just before this method was invoked by another service/thread). - 4. Inexistent row key. The specified row key might not exist (anymore). - 5. Inexistent column. The specified column and/or super column might not exist. - 6. The value stored in the column to be retrieved is not of type T (i.e. the value is stored as byte[] but retrieved as String) - 7. The Hector API used internally by the Cassandra Persistence Manager throws an unchecked exception, for whatever reason. Note that the Hector API always throws unchecked exceptions, even in case of a query on a column family or row key that does not exist. In this case, it may be worthwhile to look at how this is handled by the Hector API and Thrift API (the Hector API invokes the Thrift API). But they made different choices; where the Thrift API mostly throws checked exceptions, the Hector API catches these exceptions and rewraps and rethrows them as unchecked exceptions (extending HectorException). Also important to note is that because of Cassandra's consistency mechanism, at any point in time the API calls may fail because column families, rows or columns have just been dropped or modified by another thread (as there is no locking mechanism in Cassandra). So one could argue if methods like exists() are very useful. On the other hand; exists(columnFamily) might still be useful as column families are not created/dropped on a daily basis (as opposed to rows and columns). So WDYT? Please provide an answer to what you would expect in the cases 1-7 as described above. Regards, Ivo GX Software | Ivo Ladage-van Doorn | Product Architect | Wijchenseweg 111 | 6538 SW Nijmegen | The Netherlands | T +31(0)24 - 388 82 61 | F +31(0)24 - 388 86 21 | [email protected]<mailto:[email protected]> | www.gxsoftware.com<http://www.gxsoftware.com> | twitter.com/GXSoftware<http://twitter.com/GXSoftware>
_______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
