commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liam Coughlin <lscough...@gmail.com>
Subject Re: RES: RES: RES: Possible incubation?
Date Fri, 10 Apr 2009 15:00:07 GMT
The real problem is that Unchecked exceptions still exist, and are way over
used.

-shrug-


On Fri, Apr 10, 2009 at 8:28 AM, Andre Dantas Rocha <
andre.dantas.rocha@uol.com.br> wrote:

> I totally agree with you about HandleUtil.handle(); this is a point that I
> want to avoid either. However, the current weaving implementation isn't so
> flexible and today this is the only way it works.
>
> As I wrote in my last emails, it is still necessary to work on Mojo/weaving
> to solve this kind of problem.
>
> Andre
>
> -----Mensagem original-----
> De: Gaurav Arora [mailto:gauravarora@codercorp.com]
> Enviada em: sexta-feira, 10 de abril de 2009 09:00
> Para: Commons Developers List
> Assunto: Re: RES: RES: RES: Possible incubation?
>
> Apologies for the late reply.
>
> > 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?
>
> Hmm, when I think about it, I think it is better to throw the exception
> than return it, returning would again cause extra code in the caller.
>
> I just want to touch up on a point you mentioned in your other mail about
> HandlerUtil.handle(). I personally would love to avoid such a call at all.
> I think the entire framework should be as transparent as possible to avoid
> unnecessary code. The annotation already provides metadata for a developer
> to refer too so there isn't a need for an explicit call.
>
> Gaurav
>
> > 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message