Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Types for errors #959

Open
samuelgozi opened this issue Feb 7, 2024 · 1 comment
Open

Types for errors #959

samuelgozi opened this issue Feb 7, 2024 · 1 comment

Comments

@samuelgozi
Copy link

samuelgozi commented Feb 7, 2024

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:

workos.userManagement.authenticateWithCode({ clientId, code }).catch((error) => {
	// The error code should be as described here:
	// https://workos.com/docs/reference/user-management/authentication-errors
	if (error.code === "email_verification_required") {
		context.set.status = 401; // unauthorized
		return error;
	}

	// Additional if clauses for other errors.

	// Else let the error bubble up
	throw error;
});

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:

workos.userManagement.authenticateWithCode({ clientId, code }).catch((error) => {
	if (error instanceof AuthenticationError) {
		// handle works errors
	}

	// Else let the error bubble up
	throw error;
});

And the error will be typed!

@isaachinman
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants