Re: Checked Exceptions

[Niclas Hedhman]

Sounds good.

On Tue, Dec 6, 2016 at 5:44 PM, Paul Merlin  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

Re: Checked Exceptions

[Paul Merlin]

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.

Re: Checked Exceptions

[Niclas Hedhman]

And about annotation of exception thrown for documentation purposes; No,
Scala is Scala. In Java we can still declare the RuntimeExceptions being
thrown. That is already present in many places. Difference is that the
compiler can't check it (u, maybe that's why it is called Checked
Exceptions? :-) ).

On Mon, Dec 5, 2016 at 7:37 PM, Sandro Martini 
wrote:

> Hi Paul,
> +1 from me for the change to unchecked exceptions, like in Scala (and
> others).
>
> What do you think even on adding an annotation to better show (for
> documentation purposes, etc) unchecked exceptions that could be thrown
> (if useful) ?
> Some info here:
> http://alvinalexander.com/scala/how-to-declare-scala-
> methods-throws-exceptions
>
> Bye
>
>
> 2016-12-05 9:47 GMT+01:00 Paul Merlin :
> > Gang,
> >
> > We have some checked exceptions in core:
> >
> > - AssemblyException
> > - ActivationException
> > - PassivationException
> > - BindingException
> > - InvalidInjectionException
> > - EntityFinderException
> >
> > They get in the way, like checked exceptions do, when writing lambdas.
> > The most annoying one is AssemblyException, it prevent us from writing
> > concise application assemblies.
> >
> > I'd be in favor of changing these to non-checked exceptions.
> >
> > WDYT?
> >
> > /Paul
> >
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Checked Exceptions

[Niclas Hedhman]

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.

Cheers
Niclas

On Mon, Dec 5, 2016 at 7:37 PM, Sandro Martini 
wrote:

> Hi Paul,
> +1 from me for the change to unchecked exceptions, like in Scala (and
> others).
>
> What do you think even on adding an annotation to better show (for
> documentation purposes, etc) unchecked exceptions that could be thrown
> (if useful) ?
> Some info here:
> http://alvinalexander.com/scala/how-to-declare-scala-
> methods-throws-exceptions
>
> Bye
>
>
> 2016-12-05 9:47 GMT+01:00 Paul Merlin :
> > Gang,
> >
> > We have some checked exceptions in core:
> >
> > - AssemblyException
> > - ActivationException
> > - PassivationException
> > - BindingException
> > - InvalidInjectionException
> > - EntityFinderException
> >
> > They get in the way, like checked exceptions do, when writing lambdas.
> > The most annoying one is AssemblyException, it prevent us from writing
> > concise application assemblies.
> >
> > I'd be in favor of changing these to non-checked exceptions.
> >
> > WDYT?
> >
> > /Paul
> >
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Checked Exceptions

[Sandro Martini]

Hi Paul,
+1 from me for the change to unchecked exceptions, like in Scala (and others).

What do you think even on adding an annotation to better show (for
documentation purposes, etc) unchecked exceptions that could be thrown
(if useful) ?
Some info here:
http://alvinalexander.com/scala/how-to-declare-scala-methods-throws-exceptions

Bye


2016-12-05 9:47 GMT+01:00 Paul Merlin :
> Gang,
>
> We have some checked exceptions in core:
>
> - AssemblyException
> - ActivationException
> - PassivationException
> - BindingException
> - InvalidInjectionException
> - EntityFinderException
>
> They get in the way, like checked exceptions do, when writing lambdas.
> The most annoying one is AssemblyException, it prevent us from writing
> concise application assemblies.
>
> I'd be in favor of changing these to non-checked exceptions.
>
> WDYT?
>
> /Paul
>