Legacy error handling tends to follow the method that all functions return a code depending on success/failure. You would check this code and handle (if an error) appropriately
I've written about this at length: Exceptions vs. status returns, but briefly:
To expand on the last point: if you forget to do what you should be doing with status returns, you ignore errors. If you forget to do what you should be doing with exceptions, the exception bubbles up to the outer layer of the software where it becomes visible.
Status codes are typically better than exceptions in cases where they represent cases that a function's immediate calling code is prepared to handle. The problem with status codes is that if the immediate calling code doesn't handle them, it's likely nothing will. If code throws an exception and the immediate calling code isn't prepared to handle it, the exception will propagate to code which at least claims to be so prepared.
Here are a couple of reasons
Throwing an exception is being explicit about something went wrong which is harder to be ignored by the programmer (As the program will terminate if there is no catch block).
An exception will terminate the execution of the rest of the function and will pass the control to next catch block (If there is any in the current call stack. If there is not, then the program will terminate)
Yes, it is optional but you should always use a .catch()
handler (for Promises).
It means, we can handle many errors in many functions in a single handler like below;
storeData()
.then(changeSomething)
.then(storeData)
.catch((e) => {
// Handle the error.
})
Here we can see how to handle error for the three different functions all in one. Essentially the behavior of catch is as it would wrapping all of your functions in a synchronous try/catch.