:s/Unchecked/checked/ i suck.
On Fri, Apr 10, 2009 at 11:00 AM, Liam Coughlin <lscough...@gmail.com>wrote: > 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 >> >> >
