How does picocontainer handles constructor exceptions

[Pedro Félix]

Hi,

How does picocontainer handles exceptions (checked or unchecked) throwed by
the constructor during constructor injection?

Thanks
Pedro Félix


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

They are rethrown (and wrapped inside)  
org.picocontainer.PicoCompositionException.  Unless the original  
exception was a RuntimeException derivative, in which case it is  
directly thrown to the thing calling getComponent().

Regards,

- Paul

On Nov 5, 2009, at 11:16 AM, Pedro Félix wrote:

> Hi,
>
> How does picocontainer handles exceptions (checked or unchecked)  
> throwed by
> the constructor during constructor injection?
>
> Thanks
> Pedro Félix
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Konstantin Priblouda]

AFAIR, they are passed through to caller. But nothing prevents you from
implementing custom behaviour and catch them.

regards,

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/


--- On Thu, 11/5/09, Pedro Félix <pedrofelix@...> wrote:

> From: Pedro Félix <pedrofelix@...>
> Subject: [picocontainer-user] How does picocontainer handles constructor exceptions
> To: user@...
> Date: Thursday, November 5, 2009, 7:16 PM
> Hi,
>
> How does picocontainer handles exceptions (checked or
> unchecked) throwed by
> the constructor during constructor injection?
>
> Thanks
> Pedro Félix
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Pedro Félix]

Thanks for the reply.

1) Where can I find more information regarding this subject?

2) Consider the following scenario

        User->A->B->C

        a) User code requests an A instance
        b) Type A has an optional dependency on B
        c) Type B has a mandatory dependency on C
        d) The construction of a C instance results in an exception

The exception in C construction results on an exception bubbling up to the
initial call requesting an A instance?
Or, since B is not mandatory, the request for A succeeds?

Thanks
Pedro Félix

> -----Original Message-----
> From: Konstantin Priblouda [mailto:kpriblouda@...]
> Sent: quinta-feira, 5 de Novembro de 2009 19:23
> To: user@...
> Subject: Re: [picocontainer-user] How does picocontainer handles
> constructor exceptions
>
> AFAIR, they are passed through to caller. But nothing prevents you from
> implementing custom behaviour and catch them.
>
> regards,
>
> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
> JTec quality components: http://www.pribluda.de/projects/
>
>
> --- On Thu, 11/5/09, Pedro Félix <pedrofelix@...> wrote:
>
> > From: Pedro Félix <pedrofelix@...>
> > Subject: [picocontainer-user] How does picocontainer handles
> constructor exceptions
> > To: user@...
> > Date: Thursday, November 5, 2009, 7:16 PM
> > Hi,
> >
> > How does picocontainer handles exceptions (checked or
> > unchecked) throwed by
> > the constructor during constructor injection?
> >
> > Thanks
> > Pedro Félix
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

It will bubble all the way to the creation of user (thereby vetoing  
it) .... if A had a mandatory dep on B

Pico will always choose a path that satisfies the constructor with the  
most args.  It will still get the injection-time exception as  
described above.  It has to call a constructor to witness the  
exception, it can't exclude C as an injectee at any time - it is  
registered therefore it is a candidate for injection.

Regards,

- Paul

On Nov 5, 2009, at 1:49 PM, Pedro Félix wrote:

> Thanks for the reply.
>
> 1) Where can I find more information regarding this subject?
>
> 2) Consider the following scenario
>
> User->A->B->C
>
> a) User code requests an A instance
> b) Type A has an optional dependency on B
> c) Type B has a mandatory dependency on C
> d) The construction of a C instance results in an exception
>
> The exception in C construction results on an exception bubbling up  
> to the
> initial call requesting an A instance?
> Or, since B is not mandatory, the request for A succeeds?
>
> Thanks
> Pedro Félix
>
>> -----Original Message-----
>> From: Konstantin Priblouda [mailto:kpriblouda@...]
>> Sent: quinta-feira, 5 de Novembro de 2009 19:23
>> To: user@...
>> Subject: Re: [picocontainer-user] How does picocontainer handles
>> constructor exceptions
>>
>> AFAIR, they are passed through to caller. But nothing prevents you  
>> from
>> implementing custom behaviour and catch them.
>>
>> regards,
>>
>> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
>> JTec quality components: http://www.pribluda.de/projects/
>>
>>
>> --- On Thu, 11/5/09, Pedro Félix <pedrofelix@...> wrote:
>>
>>> From: Pedro Félix <pedrofelix@...>
>>> Subject: [picocontainer-user] How does picocontainer handles
>> constructor exceptions
>>> To: user@...
>>> Date: Thursday, November 5, 2009, 7:16 PM
>>> Hi,
>>>
>>> How does picocontainer handles exceptions (checked or
>>> unchecked) throwed by
>>> the constructor during constructor injection?
>>>
>>> Thanks
>>> Pedro Félix
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Pedro Félix]

> It has to call a constructor to witness the
> exception, it can't exclude C as an injectee at any time - it is
> registered therefore it is a candidate for injection.
Yes, I understand that C constructor will always be called. However, since B
is not mandatory, the exception throw by C constructor could (at least in
theory) be ignored and A be constructed without a B instance.

Thanks
Pedro

> -----Original Message-----
> From: Paul Hammant [mailto:paul@...]
> Sent: quinta-feira, 5 de Novembro de 2009 22:18
> To: user@...
> Subject: Re: [picocontainer-user] How does picocontainer handles
> constructor exceptions
>
> It will bubble all the way to the creation of user (thereby vetoing
> it) .... if A had a mandatory dep on B
>
> Pico will always choose a path that satisfies the constructor with the
> most args.  It will still get the injection-time exception as
> described above.  It has to call a constructor to witness the
> exception, it can't exclude C as an injectee at any time - it is
> registered therefore it is a candidate for injection.
>
> Regards,
>
> - Paul
>
> On Nov 5, 2009, at 1:49 PM, Pedro Félix wrote:
>
> > Thanks for the reply.
> >
> > 1) Where can I find more information regarding this subject?
> >
> > 2) Consider the following scenario
> >
> > User->A->B->C
> >
> > a) User code requests an A instance
> > b) Type A has an optional dependency on B
> > c) Type B has a mandatory dependency on C
> > d) The construction of a C instance results in an exception
> >
> > The exception in C construction results on an exception bubbling up
> > to the
> > initial call requesting an A instance?
> > Or, since B is not mandatory, the request for A succeeds?
> >
> > Thanks
> > Pedro Félix
> >
> >> -----Original Message-----
> >> From: Konstantin Priblouda [mailto:kpriblouda@...]
> >> Sent: quinta-feira, 5 de Novembro de 2009 19:23
> >> To: user@...
> >> Subject: Re: [picocontainer-user] How does picocontainer handles
> >> constructor exceptions
> >>
> >> AFAIR, they are passed through to caller. But nothing prevents you
> >> from
> >> implementing custom behaviour and catch them.
> >>
> >> regards,
> >>
> >> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
> >> JTec quality components: http://www.pribluda.de/projects/
> >>
> >>
> >> --- On Thu, 11/5/09, Pedro Félix <pedrofelix@...> wrote:
> >>
> >>> From: Pedro Félix <pedrofelix@...>
> >>> Subject: [picocontainer-user] How does picocontainer handles
> >> constructor exceptions
> >>> To: user@...
> >>> Date: Thursday, November 5, 2009, 7:16 PM
> >>> Hi,
> >>>
> >>> How does picocontainer handles exceptions (checked or
> >>> unchecked) throwed by
> >>> the constructor during constructor injection?
> >>>
> >>> Thanks
> >>> Pedro Félix
> >>>
> >>>
> >>> -------------------------------------------------------------------
> --
> >>> To unsubscribe from this list, please visit:
> >>>
> >>>     http://xircles.codehaus.org/manage_email
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe from this list, please visit:
> >>
> >>    http://xircles.codehaus.org/manage_email
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

Pedro,

>> It has to call a constructor to witness the
>> exception, it can't exclude C as an injectee at any time - it is
>> registered therefore it is a candidate for injection.

> Yes, I understand that C constructor will always be called. However,  
> since B
> is not mandatory, the exception throw by C constructor could (at  
> least in
> theory) be ignored and A be constructed without a B instance.

I'm not sure that PicoContainer should have that behavior by detault.  
In fact I think it pretty bad.  However, we're into facilitating other  
people's visions...

For your use case, would you like us to catch an exception, then try  
another permutation of component deps that may work, then silently  
return an instance of the type that was the subject of getComponent() ?

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jörg Schaible-2]

Paul Hammant wrote at Freitag, 6. November 2009 00:10:

> Pedro,
>
>>> It has to call a constructor to witness the
>>> exception, it can't exclude C as an injectee at any time - it is
>>> registered therefore it is a candidate for injection.
>
>> Yes, I understand that C constructor will always be called. However,
>> since B
>> is not mandatory, the exception throw by C constructor could (at
>> least in
>> theory) be ignored and A be constructed without a B instance.
>
> I'm not sure that PicoContainer should have that behavior by detault.
> In fact I think it pretty bad.  However, we're into facilitating other
> people's visions...
>
> For your use case, would you like us to catch an exception, then try
> another permutation of component deps that may work, then silently
> return an instance of the type that was the subject of getComponent() ?

Maybe we can mark dependencies of a component as optional and then look for
alternatives:

class X {
 X(Foo foo, @Optional Bar bar){}
}

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Pedro Félix]

Paul,

Thanks for the reply.
I really don't have a concrete use case for this functionality.

I'm currently just studying Dependency Injection (DI) concepts and was
curious about the way that constructor exceptions are handled by the several
containers.
Namely, I was thinking about the different solutions to handle this
situations:

        Hypothesis 1: Forbid checked exceptions on constructors and "bubble
up" unchecked exceptions

        Hypothesis 2: Allow checked exceptions on constructors and also
"bubble them up"

        Hypothesis 3: Try to recover from exception, namely if the
dependency is not mandatory.

Why do you think that this last behavior "is pretty bad"?

Once again, thanks.

Regards
Pedro Félix

> -----Original Message-----
> From: Paul Hammant [mailto:paul@...]
> Sent: quinta-feira, 5 de Novembro de 2009 23:10
> To: user@...
> Subject: Re: [picocontainer-user] How does picocontainer handles
> constructor exceptions
>
> Pedro,
>
> >> It has to call a constructor to witness the
> >> exception, it can't exclude C as an injectee at any time - it is
> >> registered therefore it is a candidate for injection.
>
> > Yes, I understand that C constructor will always be called. However,
> > since B
> > is not mandatory, the exception throw by C constructor could (at
> > least in
> > theory) be ignored and A be constructed without a B instance.
>
> I'm not sure that PicoContainer should have that behavior by detault.
> In fact I think it pretty bad.  However, we're into facilitating other
> people's visions...
>
> For your use case, would you like us to catch an exception, then try
> another permutation of component deps that may work, then silently
> return an instance of the type that was the subject of getComponent() ?
>
> - Paul
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Konstantin Priblouda]

--- On Fri, 11/6/09, Pedro Félix <pedrofelix@...> wrote:

> Namely, I was thinking about the different solutions to
> handle this
> situations:
>
>     Hypothesis 1: Forbid checked exceptions
> on constructors and "bubble
> up" unchecked exceptions

Checked exceptions are enforced at compile time.  With the reflection, all exceptions become  unchecked.

>     Hypothesis 3: Try to recover from
> exception, namely if the
> dependency is not mandatory.   
>
> Why do you think that this last behavior "is pretty bad"?
>

Because it's pretty difficult to imagine how to recover from  object creation failure.

regards,

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Pedro Félix]

See comments below

>
> > Namely, I was thinking about the different solutions to
> > handle this
> > situations:
> >
> >     Hypothesis 1: Forbid checked exceptions
> > on constructors and "bubble
> > up" unchecked exceptions
>
> Checked exceptions are enforced at compile time.  With the reflection,
> all exceptions become  unchecked.

Well, this prohibition would be enforced on runtime. It is possible, using
reflection, to determine if a constructor throws checked exceptions.
However, it may not make lots of sense.
 
> >     Hypothesis 3: Try to recover from
> > exception, namely if the
> > dependency is not mandatory.
> >
> > Why do you think that this last behavior "is pretty bad"?
> >
>
> Because it's pretty difficult to imagine how to recover from  object
> creation failure.
Well, I'm not recovering the creation of the object that thrown the
exception in the ctor. Instead, I'm trying to "recover" the creation of a
directly or indirectly dependent object, assuming that this dependency is
optional.

> regards,
Thanks, regards
Pedro



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jörg Schaible-2]

Hi Pedro,

Pedro Félix wrote at Freitag, 6. November 2009 13:57:

> See comments below
>>
>> > Namely, I was thinking about the different solutions to
>> > handle this
>> > situations:
>> >
>> > Hypothesis 1: Forbid checked exceptions
>> > on constructors and "bubble
>> > up" unchecked exceptions
>>
>> Checked exceptions are enforced at compile time.  With the reflection,
>> all exceptions become  unchecked.
>
> Well, this prohibition would be enforced on runtime. It is possible, using
> reflection, to determine if a constructor throws checked exceptions.
> However, it may not make lots of sense.

It does not mater, since you cannot rethrow the checked exception without
declaring it for your method again.

>> > Hypothesis 3: Try to recover from
>> > exception, namely if the
>> > dependency is not mandatory.
>> >
>> > Why do you think that this last behavior "is pretty bad"?
>> >
>>
>> Because it's pretty difficult to imagine how to recover from  object
>> creation failure.
> Well, I'm not recovering the creation of the object that thrown the
> exception in the ctor. Instead, I'm trying to "recover" the creation of a
> directly or indirectly dependent object, assuming that this dependency is
> optional.

It's the default behaviour that makes most sense. A dependency that cannot
be satisfied leaves the depending component in an unspecified
state. "Assuming" that the dependency is optional is not really valid here.
Explicitly expressing that it is optional - then yes. See my other mail.

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Pedro Félix]

> >> > Namely, I was thinking about the different solutions to
> >> > handle this
> >> > situations:
> >> >
> >> > Hypothesis 1: Forbid checked exceptions
> >> > on constructors and "bubble
> >> > up" unchecked exceptions
> >>
> >> Checked exceptions are enforced at compile time.  With the
> reflection,
> >> all exceptions become  unchecked.
> >
> > Well, this prohibition would be enforced on runtime. It is possible,
> using
> > reflection, to determine if a constructor throws checked exceptions.
> > However, it may not make lots of sense.
> It does not mater, since you cannot rethrow the checked exception without declaring it for your method again.

I understand "you cannot rethrow the checked exception without declaring it for your method again", but don't understand your point.

>
> >> > Hypothesis 3: Try to recover from
> >> > exception, namely if the
> >> > dependency is not mandatory.
> >> >
> >> > Why do you think that this last behavior "is pretty bad"?
> >> >
> >>
> >> Because it's pretty difficult to imagine how to recover from  object
> >> creation failure.
> > Well, I'm not recovering the creation of the object that thrown the
> > exception in the ctor. Instead, I'm trying to "recover" the creation
> of a
> > directly or indirectly dependent object, assuming that this
> dependency is
> > optional.
>
> It's the default behaviour that makes most sense. A dependency that
> cannot
> be satisfied leaves the depending component in an unspecified
> state. "Assuming" that the dependency is optional is not really valid
> here.
> Explicitly expressing that it is optional - then yes. See my other
> mail.

I completely agree. This behavior would only make sense if the dependency is explicitly marked as optional by the dependant type.

Thanks
Pedro
 
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jörg Schaible-2]

Pedro Félix wrote:

>> >> > Namely, I was thinking about the different solutions to
>> >> > handle this
>> >> > situations:
>> >> >
>> >> > Hypothesis 1: Forbid checked exceptions
>> >> > on constructors and "bubble
>> >> > up" unchecked exceptions
>> >>
>> >> Checked exceptions are enforced at compile time.  With the
>> reflection,
>> >> all exceptions become  unchecked.
>> >
>> > Well, this prohibition would be enforced on runtime. It is possible,
>> using
>> > reflection, to determine if a constructor throws checked exceptions.
>> > However, it may not make lots of sense.
>> It does not mater, since you cannot rethrow the checked exception without
>> declaring it for your method again.
> I understand "you cannot rethrow the checked exception without declaring
> it for your method again", but don't understand your point.

I reread this topic any my comment does really not make a lot sense - so
forget it ;-)

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email