The real problem is that Unchecked exceptions still exist, and are way over used.
-shrug- On Fri, Apr 10, 2009 at 8:28 AM, Andre Dantas Rocha < andre.dantas.ro...@uol.com.br> wrote: > 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 > >
