Three points from discussion in https://github.com/reactjs/react-redux/issues/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.
stopWorkLoopTimer();
    }
    
    if (errorToThrow !== null) {
      throw errorToThrow;
    }
  }
   Returns the boundary that captured the error, or null if the error is ignored
  function captureError(failedWork: Fiber, error: mixed): Fiber | null {
    
    ReactCurrentOwner.current = null;
    if (__DEV__) {
      ReactDebugCurrentFiber.resetCurrentFiber();
    }
     Search for the nearest error boundary.
    let boundary: Fiber | null = null;
     Passed to logCapturedError()
    let errorBoundaryFound: boolean = false;
    let willRetry: boolean = false;
    let errorBoundaryName: string | null = null;
     Host containers are a special case. If the failed work itself is a host
     container, then it acts as its own boundary. In all other cases, we
     ignore the work itself and only search through the parents.
    if (failedWork.tag === HostRoot) {
      boundary = failedWork;
      if (isFailedBoundary(failedWork)) {
        
        
        
        didFatal = true;