Directly throw Supabase error in server utility functions

philliphartin commented 2 months ago

Remove opinionated use of `createError` in favor of direct throw for better error handling

Types of changes

[ ] Bug fix (a non-breaking change which fixes an issue)
[x] New feature (a non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

This change removes the use of createError and replaces it with a direct throw. This modification allows downstream users more flexibility in catching and handling errors, fitting the specific needs of their applications.

Why is this change required? What problem does it solve?

The previous implementation using createError restricted how errors could be caught and handled by downstream users. By directly throwing errors, developers now have the ability to catch and manage these errors in a way that best suits their application's requirements.

Resolves: N/A

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes (if not applicable, please state why)

netlify[bot] commented 2 months ago

Deploy request for n3-supabase pending review.

Visit the deploys page to approve it

Name	Link
Latest commit	2730ea8650f239da4efd04574eacb4790fc7afb3

th1m0 commented 2 months ago

@philliphartin could you provide an example where this would be useful?

philliphartin commented 2 months ago

@th1m0

@philliphartin could you provide an example where this would be useful?

Sure, let's say you're building an API endpoint that handles invitations to join a platform. The endpoint could be capable of determining if the invitation link is being opened by an authenticated user or not with the serverSupabaseUser utility.

Example

const user =  await serverSupabaseUser(event)

If the user is available, then they can associate the invitation to that user. If the user is null or undefined, then the endpoint author can handle that case. If there was an actual error with the supabase call, then the try/catch case is invoked and the endpoint author can also handle that accordingly.

th1m0 commented 2 months ago

Sorry for the late response on this. Currently it is also possible to catch the error thrown with createError, which is provided by Nuxt. That's why I asked for an example of where this change would be specifically useful.

atinux commented 2 months ago

Please take a look at https://github.com/unjs/h3/blob/2d941d3cfb1dddf543d48abe23d13488c88c7432/src/error.ts#L82

the H3Error extends the Error instance so it's exactly the same but it better when dealing with HTTP errors.

atinux commented 2 months ago

Re-opening as I believe it might be best to use throw createError(error) to forward all properties from the incoming Supabase error

philliphartin commented 2 months ago

Re-opening as I believe it might be best to use throw createError(error) to forward all properties from the incoming Supabase error

That seems like a good idea. Would you like me to make those changes and commit back to the PR?

larbish commented 2 months ago

@philliphartin I think you can keep this one and rename it.

nuxt-modules / supabase