I opened OAK-3745 and attached a patch to it. It's really trivial, but it would be better if somebody would look over it.
2015-12-08 11:08 GMT+01:00 Francesco Mari <[email protected]>: > 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 >> > >
