Error handling
Review how to handle errors (exceptions) generated by both your own Durable Object code as well as exceptions thrown by Durable Objects’ infrastructure (such as overloads or network errors).
How exceptions are thrown
Durable Objects can throw exceptions in one of two ways:
- An exception can be thrown within the user code which implements a Durable Object class. The resulting exception will have a
.remote
property set toTrue
in this case. - An exception can be generated by Durable Object’s infrastructure. Some sources of infrastructure exceptions include: transient internal errors, sending too many requests to a single Durable Object, and too many requests being queued due to slow or excessive I/O (external API calls or storage operations) within an individual Durable Object. Some infrastructure exceptions may also have the
.remote
property set toTrue
– for example, when the Durable Object exceeds its memory or CPU limits.
Refer to Troubleshooting to review the types of errors returned by a Durable Object and/or Durable Objects infrastructure and how to prevent them.
Understanding stubs
A Durable Object stub is a client Object used to send requests to a remote Durable Object. To learn more about how to make requests to a Durable Object, refer to Create Durable Objects stubs and Access a Durable Objects from a Worker.
Example
Any uncaught exceptions thrown by a Durable Object or its infrastructure will be propagated to the callsite of the client. Catching these exceptions allows you to retry creating the Durable Object stub and sending requests.