"Error: null" in the captured error warning due to cross-origin issues

[gaearon]

Three points from discussion in reduxjs/react-redux#756:

• Due to https://bugs.chromium.org/p/chromium/issues/detail?id=701371, environments like CodeSandbox show Error: null in our “React caught an error” warning. Let’s consider skipping both as they’re not very useful and look like a bug. Error: null looks like a separate error and draws attention away from the real error just above.

• In any case we should probably not print The error was thrown at: if we don’t have a JS stack.

• There is a related issue. What do we pass to error boundary if we caught null? It seems that most error boundaries will intuitively do something like if (this.state.error) or read error.message, which null will break. There are other falsy values too like '' and undefined. My proposal is we always wrap primitives into our own Error objects that we pass to the boundary.

[sebmarkbage]

I'm not a huge fan of the magical behavior of automatically wrapping. Also takes us further away from just being try/catch semantics.

If you have the if (this.state.error) fail, you'll probably hit an infinite loop error instead that you can fix.

Just build a proper HoC once and be done with it. :)

[acdlite]

Tend to agree with @sebmarkbage about automatic wrapping.

If you have the if (this.state.error) fail, you'll probably hit an infinite loop error instead that you can fix.

Isn't the more likely scenario that the error would propagate to the next boundary, and eventually to the root? Not sure where the infinite loop comes into play.

I do think we should use a custom error for cross-origin errors (!errorEvent.isTrusted) (Edit: nevermind, that doesn't mean what I thought it did), since that is DEV-only behavior and does not match try/catch semantics.

[sebmarkbage]

Ah, you're right. The bubbling should happen.

Agreed. If we can correctly differentiate between "null because not trusted" and "null because throw null/undefined" then we can pass a custom error in the former case.

[gaearon]

Another similar report, not clear to me yet if it’s caused by the same issue or not.
#10294 (comment)

[sebmarkbage]

I assume serving scripts from file:/// might trigger this?