Hi, I agree with what you said.
- Annotation processing: let's keep that in mind, and come back to it later. Simo, can you create the wiki page for us? - Renaming methods: I hope that I get the time to create a patch this weekend - Wrapper Exceptions: I thing we should discuss, how a exception hierarchy could look like. I'll make a suggestion ASAP. Regards, Benedikt 2012/6/15 Simone Tripodi <[email protected]>: > Thanks a lot for monitoring BU2 James, and thanks for the feedbacks! > this sounds to be the way to go! > > now waiting for patches from Benedikt :) > > best, > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > On Fri, Jun 15, 2012 at 1:05 PM, James Carman > <[email protected]> wrote: >> On Fri, Jun 15, 2012 at 1:50 AM, Simone Tripodi >> <[email protected]> wrote: >>> >>> >>> > 2. Wrap checked exceptions into RuntimeExceptions. The question is, >>> > what a user can do to recover from one of those exceptions. Only if >>> > there is something the user can do, it would make sense to throw a >>> > checked exception. >>> >>> this is currently the option I'd prefer! >>> >> >> +1! This is one thing I hate about BeanUtils. I really hate having >> to catch all these exceptions and every project where I use BU, I >> usually end up "wrapping" the calls to do this very thing, since >> there's really nothing you can do about it typically and it would >> indicate a programming error, not some runtime condition which you can >> code around. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
