-
Notifications
You must be signed in to change notification settings - Fork 426
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename ResultExt::to_field_err? #69
Comments
Sounds reasonable, but while we're on the topic of field errors... I feel that error handling is a bit unergonomic right now. For example, if you're doing stuff that can fail, you've got two options in practice:
Converting error types yourself feels like a shortcoming on Juniper's side; why should a user have to care about that? On the other hand, using the macro looks a bit weird when you're chaining operations that can fail: So, I wonder if we could make the macros support any kind of |
IIRC both the So an alternative could be to define a concrete type struct FieldError {
message: String
}
type FieldResult<T> = Result<T, FieldError>;
impl<E> From<E> for FieldError where E: Display {
fn from(err: E) -> FieldError {
FieldError { message: format!("{}", err) }
}
} This would enable people to use the field foo() {
let txn = db.transaction()?;
...
} ... as well as enable the use of |
Deprecating the macros is something we already talked about. I'll write more here later, but just for now: #40 is also relevant for this. |
Both ResultExt and the jtry macro were removed in |
The method name ResultExt::fo_field_err is a bit confusing, since it implies an Err return type.
We could leave it as is, or rename it to
to_field_result
orto_field_res
.If we rename, it should definitely be before 1.0.
Thoughts, @mhallin ?
The text was updated successfully, but these errors were encountered: