Major DX change: response and error handling about supabase-js HOT 15 CLOSED

Throwing errors by default, or have that as an option on createClient, would be a great improvement for us too. We use a lot of rxjs with supabase and regular error throwing would make the whole process more logical. Now we have to remember to write throwOnError after every query, because otherwise the error will go silent

from supabase-js.

Can we set this as a default behaviour globally via a parameter or smth? This is super unusual behaviour, as SDKs ussually throw errors, otherwise we have to add lots of additional checks around that which doesn't make sense.

from supabase-js.

Does this error handling include programmer errors?

I don't think this should be expected, just catch and rethrow unexpected errors. As you say, handling every possible error would be unwieldy. We should just shape expected errors.

so there's no need to use the data field in place of body.

This one is just a preference. I guess we should decide now what is the more appropriate name for the key. IMO body seems like a throwback to when we used ajax used to request HTML snippets that would be injected into HTML.

Currently the error handling looks more like this

if (!ok) { // status code is not 2XX
  return // abort
}

I'd far prefer this one to look like the suggested change (if (error)). The term ok is unexpected, and error is very clear

from supabase-js.

This is not specific to .rpc(). You can use .throwOnError() on .select(), .insert(), etc. and it will throw errors instead of returning it in the response object. See the example I linked above.

from supabase-js.

Does this error handling include programmer errors? Say I pass a list to match where I expect an object, and I use Object.keys on it. Having to handle each and every kind of such exceptions in JS, with the appropriate error messages, is very painful IMO.

For the record, supabase/postgrest-js#93 uses a fetch polyfill for the HTTP client, so there's no need to use the data field in place of body. Currently the error handling looks more like this, though we can shape it to your proposed format:

const { ok, body: products } = await supabase.from('products').select('*')
if (!ok) { // status code is not 2XX
  alert(products.message) // PostgREST's error is stored in body (`T | T[] | PostgrestError`) in case of error
  return // abort
}
console.log(`Found ${products.length} products.`)

from supabase-js.

Tasks:

• Update postgrest-js
• Update gotrue-js
• Update realtime-js
• Update supabase-js
  • Install new libs
  • Change the realtime to work with one socket connection per client

Also solves:

• Client & server side method for validating user auth token : supabase/supabase#147
• supabase.auth.logout() throws "Invalid user" error: #15

from supabase-js.

Are there plans to expose the Content-Range header in the response object?

from supabase-js.

@stupidawesome is there a use case for this? PostgREST supports this, but we haven't really considered having this in. If you just want the COUNT, there's an open issue for it.

from supabase-js.

const { error, data: products } = await supabase.from('products').select('*')
if (error) {
  alert(error.message)
  return // abort
}
console.log(`Found ${products.length} products.`)

Do i still need to use try-catch after using above pattern?

from supabase-js.

You don't - if it throws it might be sign of a postgrest-js bug.

from supabase-js.

You don't - if it throws it might be sign of a postgrest-js bug.

So does supabase return network failure in error object? I think it does not. So what should i do then?

from supabase-js.

I'm not sure about the other dependencies, but postgrest-js should return network failure in error. If not, can you create an issue in supabase/postgrest-js along with your client lib verison?

from supabase-js.

import useSWR from 'swr'

function Profile() {
  const { data, error } = useSWR('/api/user', fetcher)

  if (error) return <div>failed to load</div>
  if (!data) return <div>loading...</div>
  return <div>hello {data.name}!</div>
}

Here is the text from swr documentation -
**

"If an error is thrown inside fetcher, it will be returned as error by the hook." here is link

**
So if supabase does not throw error and simply return response object how we will catch supabase error inside swr?

Will following code work then? Because in following code supabase is not throwing error, so what will be error in following code?

const { data, error } = useSWR(
    subheadingId == undefined || userid == undefined
      ? null
      : [`/subheading/${subheadingId}/${userid}`],
    async () =>
      await supabase.rpc<SharedNotesList>("subheadingg", {
        subheadingid: subheadingId,
        sharedwith: userid,
      }),
     );

from supabase-js.

If you want the .rpc() call to throw errors, you can use .throwOnError() (example: https://github.com/supabase/postgrest-js/blob/a972b993487fe99990a6be7995f0c6a2dc50b784/test/basic.ts#L136)

from supabase-js.

If you want the .rpc() call to throw errors, you can use .throwOnError() (example: https://github.com/supabase/postgrest-js/blob/a972b993487fe99990a6be7995f0c6a2dc50b784/test/basic.ts#L136)

I am not specific about rpc. take it as general supabase query and answer what i am asking please.

from supabase-js.