Lets first understand the best practices regarding handling Exceptions while designing an API or framework.
- If the client can take some alternate action to recover from the exception, make it a checked exception.
- If the client cannot do anything useful, then make the exception unchecked. By useful, I mean taking steps to recover from the exception and not just logging the exception.
From the above best practices It’s clear to use Unchecked Exceptions where client can not do anything to recover from exception and using checked exception force client to handle it.
Spring does throw runtime exceptions instead of checked exceptions. Runtime exceptions must not be catched and if they happen and if they are not catched your application will stop running with a standard java stack trace. Checked exceptions must be catched. If you do not catch a checked exception in your code, it can not be compiled.
Spring developers decided to throw runtime exceptions, so that if you do not catch an exceptions your application will break and the user gets the application exception. Their second reasoning is that most exceptions are unrecoverable so your application logic can not deal with them anyway.