commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Fortner <>
Subject Re: [VFS] Softening the exceptions...
Date Mon, 25 Oct 2010 16:49:50 GMT

At the risk of playing Devils Advocate here, what's the downside to checked
exceptions? A few extra lines of code?  I can foresee a problem with
unchecked exceptions though.  Imagine that you're using the API to build a
desktop application.  You want to display a dialog box to the user
indicating that some problem has occurred.  With an unchecked exception, the
stack trace and exception message may appear in a log file or in the
console, but the user would in all likelihood never see it.

Moreover if a developer is unfamiliar with the API, with a checked
exception, they would be able to make an informed decision about how to
handle the exception. The developer can easily trap the exception, and
display a semi-informative dialog indicating that something has gone wrong.
 Although the user may not be able to fix it, they would still know that a
problem occurred, and would hopefully be able to file a bug report to that
effect. If you don't want the user informed, you can always swallow the
exception. But at least, as a developer, you have a choice about how to deal
with it, and it's not something that just pops up out of no where and
surprises both user and developer.

Mark <>

On Mon, Oct 25, 2010 at 9:01 AM, James Carman <>wrote:

> On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
> <> wrote:
> > I'm not in favor of changing much at this point. I'd really like to get a
> release done without too many more changes.
> >
> There's a problem with that, Ralph.  If we publish a 2.0, we can't
> "break" the API later.  So, we'd have to go to 3.0 if we wanted to
> break anything.  So, we need to figure out if this is the way we want
> to go and do it.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message