I'm working on a typescript project that is largely callback-based. Right now I'm working on a class and I had to write some new methods using other methods. So I promisified the methods I needed and wrote the methods with try/catch + async/await. But the methods I wrote still take a callback as a parameter and the promise they return resolves to void, in order to be able to be used by the rest of the project.
I was thinking even better would be to try to make these new methods compatible with both callbacks and promises, i.e. by calling the callback if it was passed, but also returning the stuff that would be passed to the callback so that they could be used either way in the future, as part of a callback-based function or a promise chain/async await.
I'm confused about what the return type should be in the type annotations. Let's say the method is getting a user from the database. I don't want to throw inside this method because the project around it is based on the (err, data) callback structure, so thrown errors would not get caught. So I have to return something, but I'm not sure about the type annotations. Saying that the return type is User | Error seems wrong? Then calling functions would have to check the type that was returned at runtime, right?
How should errors be handled without throwing?
Are you familiar with rejected Promises?
The idiomatic way to handle errors from a Promise API is with Promise rejections, such that your returned promise would either be fulfilled with a User or rejected with an Error. This lets errors propagate try/catch style through promise chains. The same way that you would call the callback with an err in a callback-style function, you can either return Promise.reject(err) (docs) or throw err from an async function or then handler; there is not much difference between them.
As far as TypeScript is concerned, you can't and shouldn't specifically type the Error in the return value: It is assumed that all Promises might be rejected, and that the rejection reason might be of type any. I believe it is idiomatic for the rejection reason to be an Error, but much like the throw statement in JavaScript it can easily be a string or number.
See also: