Do we want the APIs to be quieter than using java.io.File for example? Or, should exceptions be thrown from similar places?
I am worried that we would make all APIs "quiet" (unchecked exceptions) as a opposed to really thinking where exceptions should be checked or return an Boolean error code (like File mkdir) OTOH, I do not know if the java.io API is perfect WRT exceptions. Gary Gregory Senior Software Engineer Rocket Software 3340 Peachtree Road, Suite 820 . Atlanta, GA 30326 . USA Tel: +1.404.760.1560 Email: [email protected] Web: seagull.rocketsoftware.com > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of James Carman > Sent: Monday, October 25, 2010 07:56 > To: Commons Developers List > Subject: Re: [VFS] Softening the exceptions... > > I've even gone as far as writing a VfsUtils class that does all the > wrapping of these exceptions into RuntimeExceptions so that the API is > less of a burden. > > On Mon, Oct 25, 2010 at 10:53 AM, Steven Siebert <[email protected]> wrote: > > +1 on this issue. > > > > I use VFS on a couple projects and this is always a bit burdensome, and on > > several occasions have indeed caught and rethrew RuntimeExceptions. Even if > > we can't/shouldn't soften them, what about typing them to be more specific? > > Having every method throwing a FileSystemException isn't always the most > > helpful =) > > > > Steve > > > > On Mon, Oct 25, 2010 at 10:46 AM, James Carman > > <[email protected]>wrote: > > > >> What do you folks think about making the exceptions extend > >> RuntimeException in 2.0? I really find it tedious to do try/catch > >> everywhere I want to ask a FileObject something (like if it exists or > >> not). > >> > >> --------------------------------------------------------------------- > >> 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]
