Directly throw Supabase error in server utility functions

[philliphartin]

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)
• 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]

👷 Deploy request for n3-supabase pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	2730ea8

[th1m0]

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

[philliphartin]

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

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]

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]

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

[philliphartin]

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]

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