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:49 GMT
:s/Unchecked/checked/

i suck.

On Fri, Apr 10, 2009 at 11:00 AM, Liam Coughlin <lscoughlin@gmail.com>wrote:

> 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