2015-12-08 10:43 GMT+01:00 Michael Dürig <[email protected]>: > > > On 8.12.15 10:38 , Francesco Mari wrote: > >> 2015-12-08 10:32 GMT+01:00 Michael Dürig <[email protected]>: >> >> IMO SNFE should be exported so upstream projects can depend on it. >>> >>>> Otherwise there is no value in throwing a specific exception in the >>>>> first >>>>> place. >>>>> >>>>> >>>>> My goal is to move the Segment Store into its own bundle without having >>>>> >>>> circular dependencies between this new bundle and oak-core. I could have >>>> tried to create two bundles - one with the exported API of the Segment >>>> Store and one with its implementation - but I prefer not to go this way >>>> at >>>> the moment. Defining a proper Segment Store API seems to require a >>>> refactoring way deeper than the one I'm doing, and I'm not sure if we >>>> want >>>> to go head first into this task, given the current changes currently in >>>> progress on the Segment Store. >>>> >>>> >>> Right, makes sense. Can we come up with a different way of (somewhat) >>> reliable conveying a SNFE up the stack so interested parties could hook >>> into it? >>> >> >> >> How about introducing a new unchecked exception in the >> org.apache.jackrabbit.oak.api package? I propose to call this exception >> something like InvalidRepositoryStateException, that implementations of >> the >> ContentRepository API can throw in case of inconsistencies. This >> exceptions >> can be checked up in the call stack (like in ValueImpl) and wrapped into >> checked exceptions when needed. >> > > +1. And use some kind of a code to signal more details of the cause. > Similar to org.apache.jackrabbit.oak.api.CommitFailedException, only better > ;-) That is, instead out of band documenting these codes (aka Wiki) make > them an enum.
Another proposal that came up offline between Michael and me is not to add any kind of code to InvalidRepositoryStateException. Implementations of the ContentRepository can subclass the exception and expose those subclasses as part of their public API. This leaves the choice to the ContentRepository implementation about which failures can be handled by the caller and which ones are considered to be unrecoverable. > > > Michael >
