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
Currently, error handling is implemented the way it is in pgx, which is by panicing and catching the panic at the transaction boundary. This is good at the interface with postgres, but for a higher level API, using the standard rust Result method of error handling is generally more ergonomic. This because interfaces signal fallibility and it allows using the standard machinery for handling and converting errors.
Here, fn new is fallible, but nothing signals its fallibility to the casual reader or implementer. require_option diverges, so the unwrap is safe (actually require_option could return String instead of Option<String>, because if it would be None, it would panic through report_error).
If new returned Result<Self, WrappersError>, this could be rewritten as, for example:
Where require_option() returns a Result<String, WrappersError>, with the error being a WrappersError::OptionNameNotFound(String), with the string representing the option name. It is now clear that fn new is fallible, and require_option is actually just options.get(<name>).ok_or(WrappersError::OptionNameNotFound(<name>))
Of course other errors could also be returned from new(). I imagine WrappersError to look something like:
Currently, error handling is implemented the way it is in pgx, which is by
panic
ing and catching the panic at the transaction boundary. This is good at the interface with postgres, but for a higher level API, using the standard rustResult
method of error handling is generally more ergonomic. This because interfaces signal fallibility and it allows using the standard machinery for handling and converting errors.Here,
fn new
is fallible, but nothing signals its fallibility to the casual reader or implementer.require_option
diverges, so theunwrap
is safe (actually require_option could returnString
instead ofOption<String>
, because if it would beNone
, it would panic throughreport_error
).If
new
returnedResult<Self, WrappersError>
, this could be rewritten as, for example:Where
require_option()
returns aResult<String, WrappersError>
, with the error being aWrappersError::OptionNameNotFound(String)
, with the string representing the option name. It is now clear thatfn new
is fallible, andrequire_option
is actually justoptions.get(<name>).ok_or(WrappersError::OptionNameNotFound(<name>))
Of course other errors could also be returned from
new()
. I imagineWrappersError
to look something like:In
FdwState
, errors would be converted to the panic-y kind:I'd be happy to make a PR implementing this by the way.
The text was updated successfully, but these errors were encountered: