Uh, that is your job as a software developer: design good APIs.
Suppose you make a data access abstraction API. Should it throw file, SQL, MongoDB, etc. exceptions, which tell the client absolutely nothing besides something like: your configuration or infrastructure is broken? Wrapping those in API-specific exceptions adds no value. I prefer an API that does not bother me with implementation details like that. If something breaks without there being much I can do besides informing the user, make it unchecked so my fault barrier can pick it up.
What I would like to know is that if I, for example, try to retrieve some data using a key, whether or not that data exists. A checked exception may be helpful here. The same is true for violating integrity rules when modifying data. Those are things for which I can offer the user a meaningful response.
I was not using it as an argument. I was stating how exceptions are generally used. I understand that this can make people dislike checked exceptions.
There is way more to a good exception strategy than a simple division between checked and unchecked. However most people are not interested in these sort of pesky details, and want to keep things “simple”,
I doubt we will ever get:
- A very easy to grasp and use, flexible exception handling construct in a language. (Although I personally think Java’s implementation is pretty good.)
- A common agreement and understanding of the not so simple proper classification of exceptions.
- The correct implementation of such a classification throughout standard and third-party libraries of a platform.