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.

Modern programming languages however follow the exception model, where if something exceptional happens that cannot be handled properly an exception gets thrown - which keeps bubbling up until its handled.

My question is why have we moved 开发者_开发知识库towards the exception model? What are the reasons behind this? Why is it better?

Explanations/links would be much appreciated.

I've written about this at length: Exceptions vs. status returns, but briefly:

1. Exceptions leaves your code clean of all the checks necessary when testing status returns on every call,
2. Exceptions let you use the return value of functions for actual values,
3. Exceptions can carry more information than a status return can,
4. Most importantly: exceptions can't be ignored through inaction, while status returns can.

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.

Here are a couple of reasons

• Ignoring an exception requires action by the developer while ignoring a bad returning value requires exactly 0 action. This, in theory, makes it more likely a developer will handle an error vs. ignoring it or not even realizing it was happening.
• Provides a cleaner separation between the point of an error and the handling. It doesn't force manual propagation of the error at every point in between.
• Exceptions can a larger and richer information payload than a simple error code. There are ways to do this with error codes but it's more of an afterthought and is a bit cumbersome.

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.

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)

For Javascript

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.