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]

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

Post by Pedro Félix
Hi,
How does picocontainer handles exceptions (checked or unchecked) throwed by
the constructor during constructor injection?
Thanks
Pedro Félix
---------------------------------------------------------------------
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/

Subject: [picocontainer-user] How does picocontainer handles constructor exceptions
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
---------------------------------------------------------------------
    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-----
Sent: quinta-feira, 5 de Novembro de 2009 19:23
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/

Subject: [picocontainer-user] How does picocontainer handles

constructor exceptions

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
---------------------------------------------------------------------
    http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

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

http://xircles.codehaus.org/manage_email

[Paul Hammant]

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

Post by 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-----
Sent: quinta-feira, 5 de Novembro de 2009 19:23
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/

Subject: [picocontainer-user] How does picocontainer handles

constructor exceptions

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
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

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

http://xircles.codehaus.org/manage_email

[Pedro Félix]

Post by Paul Hammant
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

Post by Paul Hammant
-----Original Message-----
Sent: quinta-feira, 5 de Novembro de 2009 22:18
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

Post by 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-----
Sent: quinta-feira, 5 de Novembro de 2009 19:23
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/

Subject: [picocontainer-user] How does picocontainer handles

constructor exceptions

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
-------------------------------------------------------------------

--

Post by Pedro Félix

http://xircles.codehaus.org/manage_email

--------------------------------------------------------------------

-

Post by Pedro Félix

http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

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

http://xircles.codehaus.org/manage_email

[Paul Hammant]

Pedro,

Post by Pedro Félix

Post by Paul Hammant
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]

Post by Paul Hammant
Pedro,

Post by Pedro Félix

Post by Paul Hammant
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-----
Sent: quinta-feira, 5 de Novembro de 2009 23:10
Subject: Re: [picocontainer-user] How does picocontainer handles
constructor exceptions
Pedro,

Post by Pedro Félix

Post by Paul Hammant
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
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

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

http://xircles.codehaus.org/manage_email

[Konstantin Priblouda]

Post by Pedro Félix
Namely, I was thinking about the different solutions to
handle this
    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.

Post by Pedro Félix
    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

Post by Konstantin Priblouda

Post by Pedro Félix
Namely, I was thinking about the different solutions to
handle this
    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.

Post by Konstantin Priblouda

Post by Pedro Félix
    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.

Post by Konstantin Priblouda
regards,

Thanks, regards
Pedro



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

http://xircles.codehaus.org/manage_email

[Jörg Schaible]

Hi Pedro,

Post by Pedro Félix
See comments below

Post by Konstantin Priblouda

Post by Pedro Félix
Namely, I was thinking about the different solutions to
handle this
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.

Post by Pedro Félix

Post by Konstantin Priblouda

Post by Pedro Félix
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]

Post by Konstantin Priblouda

Post by Pedro Félix

Post by Konstantin Priblouda

Post by Pedro Félix
Namely, I was thinking about the different solutions to
handle this
Hypothesis 1: Forbid checked exceptions
on constructors and "bubble
up" unchecked exceptions

Checked exceptions are enforced at compile time. With the

reflection,

Post by Pedro Félix

Post by Konstantin Priblouda
all exceptions become unchecked.

Well, this prohibition would be enforced on runtime. It is possible,

using

Post by Pedro Félix
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.

Post by Konstantin Priblouda

Post by Pedro Félix

Post by Konstantin Priblouda

Post by Pedro Félix
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

Post by Pedro Félix
directly or indirectly dependent object, assuming that this

dependency is

Post by Pedro Félix
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

Post by Konstantin Priblouda
- Jörg
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

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

http://xircles.codehaus.org/manage_email

[Jörg Schaible]

Post by Pedro Félix

Post by Konstantin Priblouda

Post by Pedro Félix

Post by Konstantin Priblouda

Post by Pedro Félix
Namely, I was thinking about the different solutions to
handle this
Hypothesis 1: Forbid checked exceptions
on constructors and "bubble
up" unchecked exceptions

Checked exceptions are enforced at compile time. With the

reflection,

Post by Pedro Félix

Post by Konstantin Priblouda
all exceptions become unchecked.

Well, this prohibition would be enforced on runtime. It is possible,

using

Post by Pedro Félix
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