Sometimes it’s useful to handle the exception somewhere near its origin so you can close related resources, lockfiles, etc. without needing a VB6 style “On Error GoTo X” global error handler that has to account for all different contexts under which the exceptional situation might have occurred.

The code that's throwing an exception typically does not know that the exception catcher will shut anything down.

And - very often, you would _not_ shut down. Examples:

* Failure/error in an individual operation or action does not invalidate all others in the set of stuff to be done.

* Failure/error regarding the interaction with one user does not mean the interaction with other users also has to fail.

* Some things can be retried after failing, and may succeed later: I/O; things involving resource use, etc.

* Some actions have more than one way to perform them, with the calling code not being able to know apriori whether all of them are appropriate. So, it tries one of them, if it fails tries another etc.