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

There are three ways in which a Durable Object can throw an exception:

• From the code within the fetch() handler defined on your Durable Object class. The resulting exception will have a .remote property set to True in this case.
• From code within the constructor method defined on your Durable Object class. The resulting exception will have a .remote property set to True in this case.
• Generated by Durable Object’s infrastructure due to transient internal errors, or because you are sending too many requests to a single Durable Object, or when too many requests are queued due to slow or excessive I/O (external API calls or storage operations) within an individual Durable Object. Some of the exceptions generated by Durable Object’s infrastructure will also have the .remote property set to True.

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 your code within a Durable Object’s fetch() handler or constructor method will be propagated to the caller’s fetch() call. Catching these exceptions allows you to retry creating the Durable Object stub and sending the request: