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: RES: Possible incubation?
Date Fri, 10 Apr 2009 11:59:37 GMT
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


Mime
View raw message