What is the point of declaring an exception, not handling it
As I understand it, if you only declare a checked exception, it will propagate through all your methods all the way down to the main method and still interrupt your normal program flow and your program will still stop running. So why not always handle checked exceptions with try / catch ... so your program doesn't terminate due to the exception? Why bother declaring an exception in a method signature? Sorry for my bad english
source to share
As I understand it, if you only declare a checked exception, it will propagate through all your methods all the way down to the main method and still interrupt your normal program flow and your program will still stop running.
Quite right. And it's good if something happens that you really can't handle.
For example, suppose you have a program that is about to update your database with some data in a file, but you cannot load the file.
You can just catch the exception, ignore it, and still overwrite the data in your database ... but that wouldn't be nice. Once you are in a situation that you were not ready for, or you fundamentally cannot continue intelligently, then stopping is a responsible thing.
Of course, if you can actually handle this exception and keep working, that's great - but in my experience there are relatively few bugs in this case. If you are writing a server application, you usually want to abort the request (and give an error message to the client). If you are writing a user interface, you can simply abandon the current operation, notify the user and let them continue ... this is a slightly different situation.
But to unconditionally catch all the exceptions and pretend they didn't happen? & L; Shiver>
source to share
The exception is that you can choose at what level to catch them; you don't need to do this immediately - sometimes it's the right thing to do, but one catch clause at the top level can handle all the other exceptions by logging them and then moving on to the next task / request (e.g. in a servlet container).
Java checked exceptions try to make this mechanism more explicit by forcing you to handle or declare exceptions. This prevents you from forgetting about the exceptions that you want to handle immediately.
However, many people believe that this was a failed experiment in language design (note that no other language has used checked exceptions) as it forces you to have some sort of exception-related code at all levels - exactly what exceptions are are designed to prevent.
source to share
For example, if the caller is better able to handle the exception.
Let's say you have a way to read a file. How does this method know what should happen if the file doesn't exist? Maybe the whole program should exit, maybe we should tell the user a popup, maybe it should log an exception and continue, maybe it should try to restore the file from the backup. Only the calling method knows, so it must implement exception handling.
source to share
This is for more complex systems. Whoever uses your code above might want to know what went wrong, so you let them handle the exception. It doesn't completely match the main one (and can't really, unless the EVERY method on the stack throws this exception, which wins the entire target.
source to share