I personally would not make an exception checked vs not checked based on which class it extended from but rather based on which ones were declared via the throws syntax and which ones were not.

“why exactly do we need them? To remind you that you need to catch business level error”
=> “need” might be a strong word, it is more about knowing which (business) exception a certain method can throw, so that I can deal with it if I want, like a warning. Sure I can have a look on the tests to see which (business) exception a service can throw but it is even clearer if it is on the signature. And what if we don’t have the sources? Worth what if there are no tests (yeaaaah then maybe I should not use the API at all )

You have a point with the other languages. I wonder how it is done to know which (business) exception can be thrown by a service. Do we just forget to deal with it? Do we deal with all the exception in only one way? Is there more test in the others languages?

I guess you said it all with : “Yes, tell me which exceptions you will throw, but don’t make me catch them if I know i don’t need to.”

Perhaps you could convince me on business level exceptions, but why exactly do we need them? To remind you that you need to catch business level error? I think you should have lots of tests to prove that the exceptions are covered, since declaring it is no guarantee that you are handling it correct, but test is a pretty good example that you are handling it correct. And if you have test, what do you need an exception declaration for.

You are right, I would be a lot less negative about checked exceptions if they were being used more sparingly, but they are not. Also, I find it interesting that there not many other languages which use them (I don’t know of any). Would you claim that Java has less bugs because of them? I think not, so why make me type all these things.

Perhaps what we need are hints. Yes, tell me which exceptions you will throw, but don’t make me catch them if I know i don’t need to.

It just seems that if you do that, then your code will always have problems and errors.

At least with catching exceptions like FileNotFoundException and dead code, the application is able to continue.

IMO Checked exceptions belong in the domain only.

Since many love unchecked exceptions, world is filled with brittle programs working only the way they were tested.

100% coverage of my module doesn’t help. Because my module misses 50% of cases when underlying libraries return/throw something unusual.

It is known as defects of commission and defects of omission. Coverage helps with commission. Checked exceptions/contracts help with omission.

I agree I often write fluky programs. It would be useful to switch checked exceptions off for such projects. (For example, see http://projectlombok.org/disableCheckedExceptions.html)

But sometimes I write server-side production code. I would make all exceptions checked there. And I would use only libraries that compile in all-exceptions-checked mode.

The over-simplified summary:
1. put a fault-bareer early in the call tree, log all errors or display them to the user there
2. use unchecked exceptions almost everywhere
3. use checked exceptions in case of Contingencies – where “Contingency – An expected condition demanding an alternative response from a method that can be expressed in terms of the method’s intended purpose. The caller of the method expects these kinds of conditions and has a strategy for coping with them.”

This way, you have your app secured (by fault-bareers), unnecessary exceptions don’t pollute your code and compiler helps you when you want to.

Clearly, some problems with checked exceptions remain (when you use functional style for example), but Barry’s rules help in most cases – I can recommend them.