Sounds good. On Tue, Dec 6, 2016 at 5:44 PM, Paul Merlin <[email protected]> wrote:
> Le 2016-12-05 13:04, Niclas Hedhman a écrit : > >> I am also "kind of" ok with removing the checked exceptions. But there are >> a couple of places where java.lang.Exception is declared in the interface, >> as a convenience to the user implementing it. Unless really strong >> reasons, >> I think that should remain, and perhaps even be extended where users are >> implementing. >> > > Yep, makes sense. > > > After looking at the exceptions a bit: > > BindingException and InvalidInjectionException > are internal so fine to keep as checked. > > EntityFinderException should be unchecked > just like EntityStoreException. > > AssemblyException begs to be unchecked > for nicer assemblies > > > ActivationException and PassivationException are thrown, > when activating/passivating the application, layers, > modules and services. That can happen both at bootstrap > and shutdown time and during runtime with lazy services > or passivated and (re)activated services. > > [app, layer, module].activate() throws ActivationException > [app, layer, module].passivate() throws PassivationException > > serviceRef.activate() throws ActivationException > serviceRef.passivate() throws PassivationException > > Users implementing Activators can throw Exception. > > > Now looking at InitializableException, which is unchecked. > > The API is > > Initializable::initialize() throws InitializableException > > and, MixinModel & ObjectModel catch( InitializableException ) > on fragment initialization to throw a ConstructionException. > > I'm going to change the API to allow implementors to throw > Exception. > > Exact same pattern for Entities Lifecycle and LifecycleException. > > > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
