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. >
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
