Regards

The “orthodox” position is not what you seem to think it is. Using nothing but checked exceptions has never been the orthodox position, though it’s perhaps been parodied that way by developers who still don’t want to spend time on error handling, with checked exceptions or otherwise.

Recently, several well-regarded experts, including Bruce Eckel
and Rod Johnson, have publicly stated that while they initially
agreed completely with the orthodox position on checked
exceptions, they’ve concluded that exclusive use of checked
exceptions is not as good an idea as it appeared at first, and
that checked exceptions have become a significant source of
problems for many large projects.

http://www.ibm.com/developerworks/java/library/j-jtp05254.html

http://www.tiedyedfreaks.org/eric/CheckedExceptions.xhtml

Free Online Vedios http://www.flashgamesz.net/mediacentre

I am greatly for try/finally and a top-level handeler for most exceptions. I do handle ones that I can (which isn’t all that many). Most exceptions we see at the global exception handler represent coding errors anyway (with almost all of the remaining ones being database timeout or misconfigured application).

I presume you would tell me to declare all methods as throws Exception(). That works until I need somebody else’s interface that isn’t declared as throws Exception.

Therefore, I would propose a much smaller change: when declaring methods that implement interfaces, allow loosening of the throws clause. e.g.

interface SomeInterface {
void SomeMethod();
}

class SomeClass implements SomeInterface {
void SomeMethod() throws IO.IOException() {
}
}

This is incorrect in every significant way. I was careful to attribute the idea to Matt Shulman. I have no idea if he’s “from the closure camp.” I certainly did not say that I want to remove checked exceptions. The point of my post is that a simpler language (e.g. one without checked exceptions) is not necessarily a better language. Rather than being a “pet obfuscation”, closures are an example of a language feature that more than carries its conceptual weight by enabling programs that are more clear than in their absence.

Java’s exception handling is the single best error handling and reporting mechanism ever built into a programming language

Not even close. Erlang’s supervision tree-based error handling and reporting is a clear contender for the title of “single best error handling and reporting mechanism ever”, Java’s exception system — with or without checked exceptions — won’t be in a lifetime.