I agree with Mark's point about unfamiliar developers benefiting from checked exceptions. Unlike James, I like checked exceptions =), and I have established "elegant" recoveries from various resource exceptions (IO, for example) under many use cases (at least in the enterprise arena).
What's everyones opinion on more "descriptive" Exception typing to allow me to handle specific failures easier (without additional testing)? I can probably go through my code and find some examples if necessary... S On Mon, Oct 25, 2010 at 12:49 PM, Mark Fortner <phidia...@gmail.com> wrote: > -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 > > > > >
