So instead of checking for failure we should just let everything bubble up and bite the user in the face? Great, everything that can go wrong and could be handled now causes "abnormal program termination". Maybe some things that are checked exceptions shouldn't be, just as some things that aren't should be. A CloneNotSupportedException might be better off as an unchecked exception, but that would depend on the scenario where it's used (in most cases it would indeed indicate a program error and thus should come to bite you, but not always, maybe you want to handle it gently by logging it and providing a nice error message before moving on without the clone in say a plugin system). But a MalformedURLException should be checked. It's almost exclusively due to faulty user input, and should be handled through notifying the user which will often mean he can correct it without having the application crash. Seems you are one of those people who need to be educated on the correct use of different exception classes... Spring seems nice only because it deals with exceptions the only way it can, by throwing them up to the user (which will be another application) to deal with, often wrapping them in unchecked exceptions for good measure. Makes handling and dealing with problems in code that uses Spring a lot harder than it could be, as there's often no indication that something's going wrong and where except by digging through multipage stacktraces after your application crashes again because something somewhere went wrong. Spring itself may be reliable when it comes to exception handling because it does nothing but pass on the responsibility to someone else, but that's its job and no proof that doing away with exception handling altogether is a good idea. Experience has taught me that not handling exceptions (which using unchecked exceptions exclusively implies) makes code less reliable, harder to write and maintain (you'll never know an exception can happen somewhere because there's no indication of it...), and often less readable and even more error prone if you do try to handle them (just catch Throwable, log it maybe, and move on as if nothing happened...).

Right on.

In my opinion, it is the RuntimeException that caused all the confusions. Exceptions should be either all checked, or all unchecked. I think the checked exceptions are powerful, but too powerful that it even overwhelmed the compiler. That's not always good though. In other words, the important thing is not whether to check or uncheck exceptions, but how the compiler/runtime respond to them. Why not just throw warnings instead of errors (just like those with generics) on checked exceptions, so that programmers, fortunately, would have a choice. (just talking rubbish here, because throwing warning instead of error will bring hell to the compiler designers lol)

A method can throw a checked exception without declaring it. It's easy. It's just not something you should do very often, because it's a bit of a kludge, and (despite unsubstantiated hand-waving to the contrary) in most cases APIs correctly distinguish checked exceptions from runtime exceptions.

An analogy: Premature optimization is considered bad, but some people argue that early (i.e. not TOO early) optimization isn't always bad. It can even be useful. I can agree on that. But, I think most people would agree that ALWAYS doing optimization from the very start would be not be a good practice. Now, imagine that the compiler somehow forced you to do just that. For me, it's the same with failure handling. Thinking about failure handling prematurely (i.e. too early) is not constructive, but thinking about failure handling early (i.e. not TOO early) can be good. However, ALWAYS thinking about failure handling from the very start is, like optimization, probably not a good practice. But the compiler does force us to do just that - which explains a LOT of the bad code I see in Java.

I get rather worried when I see supposedly experienced developers so blantantly missing the point. There might just be a case for removing checked exceptions because they are so often misused. But to describe checked exceptions as broken for that reason is just plain wrong, and it's practically criminal to suggest they should be removed to accomodate the (rather ropey) implementation of closures! Instead, experienced developers should be attempting to educate the masses as to how to correctly use checked exceptions (and exceptions in general), and perhaps they also themselves need a quick refresher of Effective Java (assuming they have a copy).

Checked exceptions have been helpful for me at least. It is enforcing good documentation standards so it helps understanding libs I use. When I have written slightly bigger apps myself, whenever I find that exception handling becomes unwieldy and starts to pollute method signatures, it has been a sign that I have structured my code incorrectly, increasing modularity has made the exception problems go away. I understand that in some problem areas and for some people it would be better without, but I think it is too late to make such a radical change in the way the language works now. Keep them please.

Not broken. Don't fix.

In my experience, Checked Exceptions were helpful when used intelligently. Some thought has to be put in to the design of the Exception classes to prevent a proliferation of Exception types that need to handled individually. Grouping them into families that could be broadly handled reduced the exception handling code greatly. Code review greatly helped the situation. Just squashing an exception and not handling it all was considered an unusual case which warranted special documentation in the "do nothing" catch block to explain why this was a bug. Printing the stack trace was never acceptable. Almost all of the hard to find bugs were due to a squashed exception that had slipped through the net. Also, don't forget to exercise the Exception Handling code in your automated test cases.

Checked Exceptions are a very good idea because you always know what error conditions you have to take into account. Therefore they increase the reliability of a program, especially one you have not written by yourself but you have to maintain. They are also very important when using libraries. Java is no language for the quick and dirty programming style or the quick hack to describe it more politely. There are many scripting languages for that purpose, one for every taste. Use Groovy or JRuby for the quickie but don't try to convert Java to yet another scripting language. I wouldn't become a good one anyway

Java apps are very reliable. I remember creating VB apps years ago that would crash; had no idea why. Or they would run fine on MOST versions of Windows and then severly defect on others. Eliminating checked exceptions is unwise. It will go towards making Java apps less reliable, guaranteed. .net should be ignored, as though it doesn't exist. It hasn't a leg to stand on unless there is a Virtual Machine for every platform and then why not make it interoperable with Java? This is not possible therfore the doom to failure (if you want to call it that). It used to be I wondered about all these "new features" and APIs in Java and wondered, why? Now I just research .net (blissfully ignorant of .net) to find out why Sun has added this bloat to Java, its really sad. Sad that Sun would give .not the time of day. I'll shut up now.

No f'ing way. And for those who don't understand why checked exceptions are needed, may I recommend reading the relevant chapters from effective Java?

Java checked exceptions are an excellent part of the java language. They are a great aid in improving the ability to establish contracts within the code. They tell implentors that the method they are about to call depends on something that may not always be available and is outside of the control of this system. It also greatly contributes to the concept of the code being the documentation.

Checked exceptions was a brave experiment, but it failed. My experience, and the evidence from code I've read is that checked exceptions have [em]reduced[/em] the reliability of code, not improved it. The fact that no other language author (that I know of, anyway) has lifted this feature from Java should tell you something.