Let me just say that I fully agree with this post. I believe most people look at the way checked exceptions are used and since that is mostly bad they assume the whole idea is bad. Since I can think of nicer solutions with checked exceptions for pretty much everything people complain about I am not willing to follow their argument.
But I suspect we would need a full library stack written with checked exceptions in a better manner to see if they can work. Peter Alexey wrote: > On Aug 18, 11:03 am, Casper Bang <[email protected]> wrote: > >> On 18 Aug., 16:51, Alexey Zinger <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
