Open cevek opened 1 month ago
Agree. Currently, the handling of suspense looks very unreliable, here is an example from a real code: https://github.com/artalar/reatom/blob/e6b042f273dbacb221ed77923f6c8582e22236dc/packages/npm-react/src/index.ts#L209-L210
Have you considered the suggestions in the exception?
Suspense Exception: This is not a real error! It's an implementation detail of
use
to interrupt the current render. You must either rethrow it immediately, or move theuse
call outside of thetry/catch
block. Capturing without rethrowing will lead to unexpected behavior.\n\nTo handle async errors, wrap your component in an error boundary, or call the promise's.catch
method and pass the result touse
Which use case are these suggestions not covering?
Problem Statement
Currently, in React's
use(promise)
mechanism, there is no straightforward way to determine whether an exception originates from a promise suspended within theuse
hook. This makes it challenging for developers to:use(promise)
and other unrelated errors, complicating error handling logic.Proposal
React should export either:
SuspenseException
class that can be used to identify errors originating from a promise suspension, oruse(promise)
.Example Usage
SuspenseException Class:
Utility Function:
Benefits
Conclusion
By exporting either a
SuspenseException
or a utility function, React would offer developers more control over managing Suspense-related errors, improving both error handling and debugging in applications.