Exception as message passing in ConstantParameter

[Paul Hammant-3]

ConstantParameter has a method like :-

>     public boolean isResolvable(PicoContainer container,  
> ComponentAdapter<?> adapter, Type expectedType,
>                                                NameBinding  
> expectedNameBinding, boolean useNames, Annotation binding) {
>         if (expectedType instanceof Class) {
>             try {
>                 verify(container, adapter, expectedType,  
> expectedNameBinding, useNames, binding);
>                 return true;
>             } catch(final PicoCompositionException e) {
>                 return false;
>             }
>         }
>         return false;
>     }

It feels a bit icky. In our larger test suite for Pico, the catch is  
called some 26 times.  I could not say for sure whether its a marginal  
or a core code-path.  Maybe not now, but verify(..) could return  
something more sophisticated than void.

- Paul


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

    http://xircles.codehaus.org/manage_email

[Konstantin Priblouda]

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


--- On Mon, 7/7/08, Paul Hammant <paul@...> wrote:

> From: Paul Hammant <paul@...>
> Subject: [picocontainer-dev] Exception as message passing in ConstantParameter
> To: dev@...
> Date: Monday, July 7, 2008, 4:31 PM
> ConstantParameter has a method like :-
>
> >     public boolean isResolvable(PicoContainer
> container,  
> > ComponentAdapter<?> adapter, Type expectedType,
> >                                              
> NameBinding  
> > expectedNameBinding, boolean useNames, Annotation
> binding) {
> >         if (expectedType instanceof Class) {
> >             try {
> >                 verify(container, adapter,
> expectedType,  
> > expectedNameBinding, useNames, binding);
> >                 return true;
> >             } catch(final PicoCompositionException e)
> {
> >                 return false;
> >             }
> >         }
> >         return false;
> >     }
>
> It feels a bit icky. In our larger test suite for Pico, the
> catch is  
> called some 26 times.  I could not say for sure whether its
> a marginal  
> or a core code-path.  Maybe not now, but verify(..) could
> return  
> something more sophisticated than void.

AFAIR, using exceptions to signal outcomes is considered
antipattern.  But it would be difficult to produce meaningful error message outside of parameters otherwise.

regards,


     

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

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

>> or a core code-path.  Maybe not now, but verify(..) could
>> return
>> something more sophisticated than void.
>
> AFAIR, using exceptions to signal outcomes is considered
> antipattern.  But it would be difficult to produce meaningful error  
> message outside of parameters otherwise.


We could use a callback. Such that ..

     void verify(PicoContainer container, Co ... etc

.. would become ..

     Verification verify(PicoContainer container, Co ... etc

     public class Verified implements Verification {
     }
     public abstract class NotVerified implements Verification {
        public abstract void throwCause();
     }

It implies that if you have verification exceptions, you throw then  
via callback impl of NotVerified

It also implies some if/else checking in various bits of the verify  
hierarchy

- Paul

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

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

>
>
> We could use a callback. Such that ..


Ignore me. The throw was in the same class, handled by extracting a  
common method. Chg #4842

- Paul

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

    http://xircles.codehaus.org/manage_email

[Konstantin Priblouda]

--- On Mon, 7/7/08, Paul Hammant <paul@...> wrote:

> We could use a callback. Such that ..
>
>      void verify(PicoContainer container, Co ... etc
>
> .. would become ..
>
>      Verification verify(PicoContainer container, Co ...
> etc
>
>      public class Verified implements Verification {
>      }
>      public abstract class NotVerified implements
> Verification {
>         public abstract void throwCause();
>      }
>
> It implies that if you have verification exceptions, you
> throw then  
> via callback impl of NotVerified

Well, this means even more  compelxity (and API is
already pretty complex)

> It also implies some if/else checking in various bits of
> the verify  
> hierarchy

On the other side, when do we need exception? If verification
is invoked as part of starting container / retrieving of component,
then exception is a good solution.

If on user request - then not.

Maybe we shall split it in 2 parts?  Or offer wrapper method for
visitors (throwing exception, protected)
 

regards,


     

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

    http://xircles.codehaus.org/manage_email