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
On master, everything returns a Result<T, ~str>. On native, error "handling" is task failure. Neither of these options are particularly great.
The Result strategy imposes an annoying burden on users who don't care about handling SQL syntax errors in the common case. ~str is also not the appropriate type for errors, but that's more easily fixable.
On the other hand, users do sometimes want to do reasonable things with failure, especially when connecting and potentially when querying (e.g. if you wanted to rewrite psql).
and so on for all of the relevant methods. I think this is probably the most workable solution.
Whatever the solution is, the error object type should be robust. We should be able to parse the SQLSTATE value of the ErrorResult to get things like NotNullViolation vs ForeignKeyViolation.
The text was updated successfully, but these errors were encountered:
On
master
, everything returns aResult<T, ~str>
. Onnative
, error "handling" is task failure. Neither of these options are particularly great.The
Result
strategy imposes an annoying burden on users who don't care about handling SQL syntax errors in the common case.~str
is also not the appropriate type for errors, but that's more easily fixable.On the other hand, users do sometimes want to do reasonable things with failure, especially when connecting and potentially when querying (e.g. if you wanted to rewrite psql).
One option is to have something like
and so on for all of the relevant methods. I think this is probably the most workable solution.
Whatever the solution is, the error object type should be robust. We should be able to parse the SQLSTATE value of the ErrorResult to get things like
NotNullViolation
vsForeignKeyViolation
.The text was updated successfully, but these errors were encountered: