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
