-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 <ja...@carmanconsulting.com>wrote: > On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers > <ralph.go...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
