commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: RES: RES: RES: Possible incubation?
Date Wed, 08 Apr 2009 19:01:59 GMT

Perhaps the annotation could be extended in some way to permit mappings of Throwable types
to Handler types.  This would (a) allow different handlers to be used for the same method,
and (b) allow the exception to be thrown as normal when no matching handler was found.

Just thinking,
Matt

--- On Wed, 4/8/09, Andre Dantas Rocha <andre.dantas.rocha@uol.com.br> wrote:

> From: Andre Dantas Rocha <andre.dantas.rocha@uol.com.br>
> Subject: RES: RES: RES: Possible incubation?
> To: "'Andre Dantas Rocha'" <andre.dantas.rocha@uol.com.br>, "'Commons Developers
List'" <dev@commons.apache.org>
> Date: Wednesday, April 8, 2009, 1:49 PM
> I agree with you in some points.
> Maybe it is better to return inside
> exceptions to the caller instead of catch them locally.
> 
> The problem, for me, remains in this part: "see if we have
> a method to
> handle such an exception by checking if a method
> handleIllegalArgumentException exists"
> 
> I believe that implement an
> handleIllegalArgumentException() method it's not
> the best solution for the problem. Maybe the best strategy
> is to overload
> handle() method for handling exceptions of handler's
> responsibility. For
> example, Instead of handleIllegalArgumentException(),
> codify a
> handle(IllegalArgumentException e):
> 
> public class MyHandler implements handler {
>    public Throwable
> handle(IllegalArgumentException e, ...) {
>      // specific code
>    }
>    
>    public Throwable handle(Throwable t, ...)
> {
>     return t;
>    }
> }
> 
> But... and if does the user specify an handler that are not
> supposed to
> handle that code? Isn't better to throw an exception
> instead of returning
> the original one?
> 
> Andre
> 
> 
> -----Mensagem original-----
> De: Gaurav Arora [mailto:gauravarora@codercorp.com]
> 
> Enviada em: quarta-feira, 8 de abril de 2009 12:37
> Para: Commons Developers List
> Assunto: Re: RES: RES: Possible incubation?
> 
> I agree with you that there is no elegant way to say what
> can and cannot
> be handled by the handler so what I suggest is let the
> handler decide what
> it can and cannot handle. Looking at the handler should
> give one a clear
> picture of what its equipped to handle.
> 
> Here's what I mean with an example:
> 
> @ExceptionHandler(MyHandler.class)
> public void foo() {
>     try {
>         doSomething();
>     } catch (Exception ex) {
>         handler.handle(ex);
>     }
> }
> 
> Assume the above method throws an
> IllegalArgumentException.
> 
> In our handler:
> public Throwable handle(Exception e) {
>     // get the type of exception
>     // see if we have a method to handle such an
> exception by checking if
> a method handleIllegalArgumentException exists
>     // if we don't simply return the exception
> back
> }
> 
> This way there is no need to explicitly define what
> exceptions can and
> cannot be handled. What is not handled is simply thrown
> back to the
> caller. But what it does is provides a very clean caller in
> the sense that
> it has no actual exception handling code, just a single
> catchAll.
> 
> I am not sure on what exceptions should be handled by the
> handle method
> itself. Asking the handler to handle all it's own
> exceptions, in a way,
> again asks you to duplicate the code, which is what Jeha is
> trying to
> remove. Otherwise, you'll need to define exception handlers
> for the
> handlers themselves which in my view can get tricky real
> fast.
> 
> I don't think that the option of rethrowing should rest
> with the caller.
> What the caller is saying is that the handler will handle
> all it's
> exceptions and it itself knows nothing about what is going
> on. Asking the
> caller to handle rethrows sort of splits the responsibility
> between the
> two which again, is something that can get tricky.
> 
> Gaurav
> 
> 
> > Hi Gurav,
> >
> > The weaving could be accomplished statically using
> ASM, BCEL, Javassist or
> > any similar tool. In my opinion, a bytecode library
> must be used only
> > during
> > compilation process; it's better (and cleaner) if the
> program does not
> > need
> > it to work.
> >
> > Personally, I think that attach handlers with specific
> exception types
> > could
> > be a problem when you have a method that throws
> exceptions of different
> > kinds. I don't think that it could be specified (in a
> elegant way) in
> > annotations. Maybe it preferable to let it more
> generic...
> >
> > I believe that the strategy of rethrowing an exception
> or not must be
> > accomplished by the caller method, and exceptions
> inside the handler must
> > be
> > tackled there. Maybe a (new) parameter could specify
> what to do.
> >
> > What do you think?
> >
> > Andre
> >
> >
> >
> > -----Mensagem original-----
> > De: Gaurav Arora [mailto:gauravarora@codercorp.com]
> > Enviada em: quarta-feira, 8 de abril de 2009 10:37
> > Para: Commons Developers List
> > Assunto: Re: RES: Possible incubation?
> >
> > I just want to take the discussion towards converting
> compile time weaving
> > to load time weaving for a second here. Please feel
> free to correct me if
> > I have gone off the wrong path here.
> > My idea is to simply have something like this:
> > 1. apply throws advice on every method which has the
> annotation
> > 2. from within the advice, call the underlying
> handler's handle method
> > 3. if a runtime exception is thrown from within the
> handler or advice let
> > it go (complies with every methods signature)
> > 4. if however a checked exception is thrown ...
> >
> > My knowledge of AOP is limited but I think the above
> should be possible
> > and would make it easier to change in the future. #4
> is something which
> > has me stumped and I can't see a way around it except
> on a good-faith
> > basis, the handler respects what the method may throw.
> Is the above
> > possible with compile time weaving? (I ask because I
> have never used
> > compile time weaving before)
> >
> > Coming back to handling only specific exceptions. I
> was thinking of
> > something along the lines of calling a particular
> method to handle a
> > particular type of exception. For example, the handler
> must have a
> > handleIllegalArgumentException if the handler is
> expected to handle
> > IllegalArgumentExceptions for the method/class. If it
> doesn't, the
> > exception is simply rethrown.
> >
> >
> > Gaurav
> >
> >> You're right. Today Transform task put the handler
> code in all catch
> >> blocks,
> >> regards type of exception. You have to do the
> calls manually if you what
> >> to
> >> be more precise.
> >>
> >> The improvement suggested by Gaurav is very useful
> and can be done in
> >> the
> >> task (or even a Mojo).
> >>
> >> Andre
> >>
> >> -----Mensagem original-----
> >> De: sebb [mailto:sebbaz@gmail.com]
> >> Enviada em: quarta-feira, 8 de abril de 2009
> 07:46
> >> Para: Commons Developers List
> >> Assunto: Re: Possible incubation?
> >>
> >> On 08/04/2009, gauravarora@codercorp.com
> <gauravarora@codercorp.com>
> >> wrote:
> >>> I think it's more valid to look at Jeha as a
> framework that only
> >>> handles
> >>>  what you ask to handle. In the case you
> describe, if you don't ask
> >>> Jeha
> >> to
> >>>  handle a certain type of exception, then
> that exception is simply
> >>>  propagated up the stack. I don't think
> it interferes with the method
> >>>  signature, unless i'm missing
> something.
> >>
> >> That may be so, but it's not mentioned in the
> Quick Start guide - the
> >> only examples catch Exception, and there is no
> indication that the
> >> Transformer task can be used to only add handlers
> for particular
> >> Exceptions.
> >>
> >>>  Gaurav
> >>>
> >>>
> >>>  > Hi Andre,
> >>>  >
> >>>  > Andre Dantas Rocha wrote at
> Dienstag, 7. April 2009 14:38:
> >>>  >
> >>>  >> Hi all,
> >>>  >>
> >>>  >> This message was originally
> sent to incubator list, but they
> >>> suggest
> >> to
> >>>  >> post it here because *maybe*
> the idea can fit in Commons project.
> >>>  >>
> >>>  >> I'm developing a framework
> called Jeha. The main idea is to provide
> >> easy
> >>>  >> exception description and
> handling using annotations in methods and
> >>>  >> classes
> >>>  >> and some commons handlers. I
> believe that the  idea is simple, but
> >>>  >> powerful.
> >>>  >>
> >>>  >> The initial code and start
> guide of framework are here:
> >>>  >>
> >>>  >
> >>
> >
> <http://sourceforge.net/project/showfiles.php?group_id=242203&package_id=294
> >>>  >> 931&release_id=650572>
> >>>  >>
> >>>  >
> >>
> >
> http://sourceforge.net/project/showfiles.php?group_id=242203&package_id=2949
> >>>  >> 31&release_id=650572
> >>>  >>
> >>>  >> I'd like to hear from community
> if this idea is valuable for a
> >> possible
> >>>  >> incubation.
> >>>  >>
> >>>  >> Please let me know your
> opinion.
> >>>  >
> >>>  > It might be only me, but I see this
> approach a bit critical. On one
> >> hand
> >>>  > you're right, writing exception
> code is quite tedious sometimes, but
> >> with
> >>>  > your solution you wipe out any
> useful method signature regarding
> >> exception
> >>>  > declaration. What happens if I
> don't wanna handle certain exception
> >> types
> >>>  > or RuntimeException instances? I
> cannot simply rethrow from the
> >> handler.
> >>>  >
> >>>  > - Jörg
> >>>  >
> >>>  >
> >>>  >
> ---------------------------------------------------------------------
> >>>  > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>  > For additional commands, e-mail: dev-help@commons.apache.org
> >>>  >
> >>>  >
> >>>
> >>>
> >>>
> >>> 
> ---------------------------------------------------------------------
> >>>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>  For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


      

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message