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:gauravar...@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:gauravar...@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:gauravar...@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:seb...@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, gauravar...@codercorp.com <gauravar...@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-unsubscr...@commons.apache.org >>>> > For additional commands, e-mail: dev-h...@commons.apache.org >>>> > >>>> > >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
