commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gaurav Arora" <gauravar...@codercorp.com>
Subject Re: RES: RES: Possible incubation?
Date Wed, 08 Apr 2009 15:37:15 GMT
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


Mime
View raw message