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 gauravarora@codercorp.com
 designates 69.56.160.2 as permitted sender)
Message-ID: <3413.122.162.113.249.1239197836.squirrel@codercorp.com>
In-Reply-To: <001501c9b844$f7e8b600$e7ba2200$@dantas.rocha@uol.com.br>
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>
    <001501c9b844$f7e8b600$e7ba2200$@dantas.rocha@uol.com.br>
Date: Wed, 8 Apr 2009 08:37:16 -0500 (CDT)
Subject: Re: RES: Possible incubation?
From: "Gaurav Arora" <gauravarora@codercorp.com>
To: "Commons Developers List" <dev@commons.apache.org>
User-Agent: SquirrelMail/1.4.13
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

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