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.
