> -----Original Message----- > From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On > Behalf Of James Carman > Sent: Monday, October 25, 2010 10:33 > To: Commons Developers List > Subject: Re: [VFS] Softening the exceptions... > > 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.
I think about this using Murphy's law: What do I want my application to do when the API throws an exception? It will, sooner than I think. While it is true that I can catch unchecked exceptions, these are /supposed/ to be programmer errors (IllegalStateException) or catastrophic (OutOfMemoryError). Checked exceptions are expected (this file is missing, the network goes down in the middle of processing, for example.) The distinction is important. Tossing checked exceptions out the window is like hiding something under the rug. You're gonna trip on it! Gary > > > > It's not a few extra lines of code. It's a few extra lines of code > everywhere you call the API (like asking if a file exists for > example). That gets old really quickly. For cases where you want to > display a message to the user that says "something bad happened, my > bad", then you would probably want to use a custom uncaughtException() > method on your thread groups. Also, you can always choose to catch > unchecked exceptions if you want. Nothing is stopping you. You're > just not forced to do 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. > > > > What do people typically do with those exceptions? Seriously, do you > retry stuff on a regular basis in your catch blocks? I would say that > it's pretty rare that folks actually do something locally meaningful > when a checked exception occurs. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
