Replies: 1 comment
-
Basically they handle different ends - one throws, and the other catches (or generates from scratch). So even if you throw, you'll want the error() function downstream as the catch. Really I'd consider error() the first-class citizen, and StatusError the mere convenience - as it's basically just Error but with a status code to pass. I personally use a combination of both in my APIs... error() tends to be less verbose, so I use it when I can, but obviously a return isn't always viable due to scoping. Luckily throwing that StatusError works great even in middleware, Durable Objects (at least with itty-durable), etc. If you wanted a single, consistent pattern throughout your code (until a downstream catch) - StatusError is the only one that should universally work, per your note. |
Beta Was this translation helpful? Give feedback.
-
Was reading the new docs. What's the benefit of using error() vs StatusError? From I understand StatusError will just throw the error down to the default .catch. This makes error catching very simple, as you just throw every error. So why even use error() at all. What's the use case?
Beta Was this translation helpful? Give feedback.
All reactions