On Aug 18, 11:03 am, Casper Bang <casper.b...@gmail.com> wrote: > On 18 Aug., 16:51, Alexey Zinger <inline_f...@yahoo.com> wrote: > > > Maybe what this discussion needs is some real-world anecdotes of checked vs > > unchecked exceptions in production environments and how they helped or not > > to save the day. > > I would think it's a fairly real-world anecdote how no other language > following Java introduced checked exceptions. Also you will have a > much easier job coming up with language guro's against them than for > them I think.
I'm not convinced of that. So far, most of the complaints come from people talking about the imposition checked exceptions create on the coder. There's grumbling of misuse and hiding of exceptions by improper logging or catching and ignoring, but not much in the way of real-world scenarios. Not saying those statements aren't grounded in reality, but let's throw out some concrete situations to dissect and see how they could have been helped. I'm not a fan of how checked exceptions are used in specific API, JSE included, but I'm not against the concept as a whole. Lately, I've been working almost exclusively on web projects, many of them using GWT. Some of those projects were started by my predecessor and, not to put the guy down, but there's some horrendous exception handling there. Lots of catch(Exception), inconsistent and often broken logging, and all sorts of nasties like that. Some of the scenarios that were very difficult to debug (and still are in some parts of the systems) are the ones, where there's use of a 3rd party Excel authoring library (jxl as I recall). Occasionally, the code comes across a situation that breaks certain assumptions (unexpected formatting, or the like) and those almost inevitably get buried in ignored exception catches. I never get proper time to go through it (not that I'm that excited to do it) and clean it up, and so time and again we bump into some new extravagant way the system breaks. Now, one would read this and say, "Aha! -- if only there were no checked exceptions, your predecessor would have written his sloppy code in a way that would allow those to propagate to the top layer (servlet container) and you would have seen it in some log and probably on some screen." Indeed, some of those exceptions are of checked variety. However, the code was written in a manner that didn't stand a chance. He simply assumed there would be no erroneous situation and dealt wrote EVERYTHING (file IO, DB, parsing/formatting, etc.) under a single try block and figured he'd just log whatever was caught in one catch (reuse, right?). And in fact, there ARE plenty of ways to handle these situations based on whatever kind of exception might arise. For instance, multiple formats might be tried on a single value before giving up, whereas a general Excel file read exception is probably unrecoverable. And then there's the unintended catching of RuntimeException that's sprinkled around there that also just lumps lots of different situations into one try/catch. This one can't be fixed by killing off checked exceptions, obviously. Overall, much of the problems could have been avoided by a better internal API design, that would separate different layers of functionality into finer granularity and would make it clear to the developer how to handle each and every exceptional situation differently, while still cleaning up resources when possible. So I don't think simply eliminating checked exceptions would have been the answer. I think both checked and unchecked have their place. Remember, that just because Java is the only language with checked exceptions, doesn't mean that it's a dead end. I do think that real world implementations have scared some people off the idea. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
