Error Handling in React 16

You could find one answer to that question in Elm[1], and indeed it does look a lot like React. Although it generally handles exceptions by never letting them happen in the first place :)

[1] http://elm-lang.org/

    > It makes me wonder what a UI language/system
    > would look like if it were designed from the
    > ground up to be declarative

I think most people have seen XSLT only in trying to do simple transformations, without getting properly under its skin. Personally I've written a bunch of stuff in it -- a testing suite, graph traversal algorithms -- that make you appreciate it's absolutely a functional declarative language.

Yep. React has to reinvent the wheel everywhere at the component boundaries. For example, one could see <Foo /> (which is really {type: Foo}) as a “reinvented” Foo() function call. Or see this.state as “reinvented” local variables, and this.props as arguments.

I think it’s expected that, as React gets more expressive (there are other features in the pipeline), it will unfortunately have to provide its own way to express these because it goes more into the language territory. But of course we’ll try our best to make these things look familiar in JS.

QML [0] was an attempt to do that. I would say it was a very successful attempt in terms of quality of the final product. It's probably the only UI toolkit that I enjoyed using so far.

[0] https://en.wikipedia.org/wiki/QML#Syntax.2C_semantics

* If error boundary could catch its own errors, what happened if it tried to render error message and threw then? It would get into an infinite loop, trying to handle its own error and failing again. Thanks to the restriction, this can never happen.

This feature is for gracefully recovering from JavaScript errors that occur in production as a result of programmer mistakes.

For example, Facebook heavily uses error boundaries in ads code. Even if one widget fails rendering, it doesn’t take down the entire page. You’re going to have some runtime errors if you use JavaScript, but this feature ensures you can gracefully recover from them (instead of just breaking the whole app as React 15 and earlier did).

There are two other effects of this change:

* React no longer has its own cryptic errors (because it doesn’t get “confused” when user code throws, and can cleanly fail fast if there is no error boundary).

* Errors reported to the boundaries have a component stack trace attached to that, so you can know where exactly in the hierarchy the failure occurred. This can be pretty useful when debugging.

I hope this helps!