Open samuelgozi opened 7 months ago
@PaulAsjes @mthadley @mattgd
Just found this issue, as I ran into the same problem myself. I would strongly suggest you export a WorkOS.APIError
enum, or something similar.
Or, if you don't want to provide an enum, at least provide a type.
Your customers need to be able to build downstream behaviour based on thrown errors.
It seems like when the internal works api (api.workos.com) throws an error you just return it. For example the api
authenticateWithCode
can throw an error for email verification, but the types for the errors are not in this library.Can you guys please add a custom error type and interfaces for your errors?
Here is how I need to handle it now:
Now I have two problems, a) my API is not typed unless I create types for all the errors manually, and b) I need to write code to handle all the workOS errors to separate them from server errors, as can be seen I the
if
clause.If you were to use custom error classes then problem "a" would be solved, and if you add types then problem "b" would be solved. Or better yet you could create both and type the classes so that we get the best of bth worlds.
My code would then look like this:
And the error will be typed!