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: ggreg...@seagullsoftware.com Web: seagull.rocketsoftware.com > -----Original Message----- > From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] 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 <smsi...@gmail.com> 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 > > <ja...@carmanconsulting.com>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: 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
