You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally, I was trying to figure out why passing in the error object to Sentry.captureException would cause Sentry to treat the error object as a POJO, and not an Error. The error response from postgrest-js was typed as PostgrestError, which clearly extends Error.
It seems that through a couple of semi-related changes (#502, #555, #562), the type PostgrestError has started having more meaning than it signed up for.
As far as I can tell, this is the issue:
If throwOnError() is used, then the error thrown by the client is a proper PostgrestError, which calls the super constructor, and would pass the check error instanceOf Error.
If throwOnError() is NOT used, then the error has the same shape as a PostgrestError, but the constructor is not used, which means it never calls the super constructor, and would not pass the check error instanceOfError.
The obvious solution would be to either separate the "thrown" error type and the "not-thrown" error type.
The text was updated successfully, but these errors were encountered:
Bug report
Describe the bug
Originally, I was trying to figure out why passing in the error object to
Sentry.captureException
would cause Sentry to treat the error object as a POJO, and not anError
. The error response from postgrest-js was typed asPostgrestError
, which clearly extendsError
.It seems that through a couple of semi-related changes (#502, #555, #562), the type
PostgrestError
has started having more meaning than it signed up for.As far as I can tell, this is the issue:
throwOnError()
is used, then the error thrown by the client is a properPostgrestError
, which calls the super constructor, and would pass the checkerror instanceOf Error
.throwOnError()
is NOT used, then the error has the same shape as aPostgrestError
, but the constructor is not used, which means it never calls the super constructor, and would not pass the checkerror instanceOfError
.The obvious solution would be to either separate the "thrown" error type and the "not-thrown" error type.
The text was updated successfully, but these errors were encountered: