Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of lscoughlin@gmail.com designates
 209.85.219.160 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=axn5sq81k3400ImQcusAIBKoLnMkH/bviaUbzSh1FfMx8+0Tj/Lq10MGgJ7vn2iH0u
         qVVsMk/k3+FyffdGvo6tkfXw46T83hEB7/GZmY5HNjfaHC0A605bcrC2sF53X8ywmQBw
         AKnJnshqTimVP/7vNx+7Vj1Si5xbyDMRygn70=
MIME-Version: 1.0
In-Reply-To: <958d2d1f0904100800p6e114655ua070bd805c2a54c4@mail.gmail.com>
References: <34629.6446201906$1239108030@news.gmane.org>
	 <grhgv7$hj$1@ger.gmane.org>
	 <1679.122.161.70.183.1239186615.squirrel@codercorp.com>
	 <25aac9fc0904080346r62934dc5n8a7f8e90c0eb04d3@mail.gmail.com>
	 <3413.122.162.113.249.1239197836.squirrel@codercorp.com>
	 <3543.122.162.113.249.1239205035.squirrel@codercorp.com>
	 <3047.122.161.70.64.1239364777.squirrel@codercorp.com>
	 <-6002479505165202322@unknownmsgid>
	 <958d2d1f0904100800p6e114655ua070bd805c2a54c4@mail.gmail.com>
Date: Fri, 10 Apr 2009 11:00:49 -0400
Message-ID: <958d2d1f0904100800i2b1c9d72sfb57624aaf9d32f8@mail.gmail.com>
Subject: Re: RES: RES: RES: Possible incubation?
From: Liam Coughlin <lscoughlin@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=0016364c749b5c746d046734a1a2

--0016364c749b5c746d046734a1a2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

: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 ov=
er
> 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 t=
o
>> > 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 abou=
t
>> HandlerUtil.handle(). I personally would love to avoid such a call at al=
l.
>> I think the entire framework should be as transparent as possible to avo=
id
>> unnecessary code. The annotation already provides metadata for a develop=
er
>> 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. F=
or
>> > 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 t=
o
>> > 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 cann=
ot
>> > 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 cle=
ar
>> > 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 metho=
d
>> > 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 calle=
r.
>> > 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 th=
e
>> > two which again, is something that can get tricky.
>> >
>> > Gaurav
>> >
>> >
>> >> Hi Gurav,
>> >>
>> >> The weaving could be accomplished statically using ASM, BCEL, Javassi=
st
>> >> 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 no=
t
>> >> need
>> >> it to work.
>> >>
>> >> Personally, I think that attach handlers with specific exception type=
s
>> >> could
>> >> be a problem when you have a method that throws exceptions of differe=
nt
>> >> 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 m=
e
>> >> 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 metho=
d
>> >> 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 possib=
le
>> >> and would make it easier to change in the future. #4 is something whi=
ch
>> >> 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 i=
n
>> >>> 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 meth=
od
>> >>>>  signature, unless i'm missing something.
>> >>>
>> >>> That may be so, but it's not mentioned in the Quick Start guide - th=
e
>> >>> 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 projec=
t.
>> >>>>  >>
>> >>>>  >> 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=3D242203&package_i=
d=3D294
>> >>>>  >> 931&release_id=3D650572>
>> >>>>  >>
>> >>>>  >
>> >>>
>> >>
>> >
>>
>> http://sourceforge.net/project/showfiles.php?group_id=3D242203&package_i=
d=3D2949
>> >>>>  >> 31&release_id=3D650572
>> >>>>  >>
>> >>>>  >> 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=F6rg
>> >>>>  >
>> >>>>  >
>> >>>>  >
>> ---------------------------------------------------------------------
>> >>>>  > 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
>>
>>
>

--0016364c749b5c746d046734a1a2--