I know Mr. Harold is much more experienced than me. It's pretty obvious he's more of an authority on most programming subjects. With that caveat I give my reaso

I know Mr. Harold is much more experienced than me. It's pretty obvious he's more of an authority on most programming subjects. With that caveat I give my reasons why I despise checked exceptions in Java. I've never seen code that got cleaner because of the use of checked exceptions. If you have a fairly complex piece of functionality that you've refactored mercilessly, it is quite possible to end up with a deep object hierarchy. If the checked exception is thrown at the bottom, that pollutes every interface on the way up the call chain to the method where the exception is handled. Also, whenever you are ready to catch the exception, you have to have a try/catch block and that aesthetically looks like an if-else statement, which means it is really easy to write it in an ugly way (merely having 3 lines of code for each the try and catch part is enough). All of this inevitably slows me down as I have to come up with a way to deal with those problems. It also frequently tempts me to just eat the checked exception rather than handle it. I also think throwing a checked exception assumes too much about how I want to use that particular class/function. Suppose I'm using some sort of parsing tool to test complicated output (say, HTML). I'm only using this in tests. I do not want to have to handle exceptions. Even if it was in production code I may not actually care about addressing anything but the happy path. I cannot effectively argue I'm not a newbie, writing buggy, shaky software. But I can't help but feel that the concerns of most programmers are more aligned with mine.