commons-dev mailing list archives

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

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

card.ly: <http://card.ly/phidias51>


On Mon, Oct 25, 2010 at 9:01 AM, James Carman <james@carmanconsulting.com>wrote:

> On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
> <ralph.goers@dslextreme.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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