Neo4j Exceptions
As protocols, APIs are an extremely important part of the product and in case you have a rich API you might face criticism:
Now if a DeadlockDetectedException, HaCommunicationException, NotFoundException(thrown if a request is made to a node, relationship or property that does not exist), NotInTransactionException, ReadOnlyIndexException or TransactionFailureException were thrown, what would I really do about it? Nothing much, unfortunately. There is no way I could be smart and recover from these. At the most I’d log it and re-throw it.
A while back I had my part of suggestions related to Neo4j API and some of those became part of the Neo4j 1.2 roadmap. Problem is not that API is not fixable, but if you want to maintain backward compatibility things are quickly becoming complicated (or leading to ugly APIs).
Update: I’ve received a couple of comments that made me realize that most probably I haven’t expressed myself too well. So here is another attempt:
- it is normal for graph databases (and embedded databases) to have richer APIs. That’s why I’ve suggested to some of the graph databases to look more into providing it as a service, as that would reduce a bit the complexity
- it is normal that a complex API would not always be obvious and perfect to everybody
- it is great to get feedback about your API (in whatever form it comes, from “your API sucks” to “it’s good, but I’d like to be able to do this and that”) as it means that:
- your users are getting deeper into your product and they care about it
- you’ll have a chance to improve it over time so new users will find a better API
- maintaining backward compatibility for complex APIs is always a challenge and you must think about this as early as possible so you can follow the same policy over time
Original title and link: Neo4j Exceptions (NoSQL databases © myNoSQL)
via: http://thought-bytes.blogspot.com/2010/12/runtimeexceptions-and-neo4j.html
