commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [VFS] Softening the exceptions...
Date Mon, 25 Oct 2010 15:05:02 GMT
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: ggregory@seagullsoftware.com
Web: seagull.rocketsoftware.com  



> -----Original Message-----
> From: jcarman@carmanconsulting.com [mailto:jcarman@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 <smsiebe@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
> > <james@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message