Rename ResultExt::to_field_err? about juniper

[mhallin]

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:

• Import juniper::ResultExt, write e.g. let txn = db.transaction().to_field_result()?;
• Use jtry!, e.g. let txn = jtry(db.transaction());

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: jtry!(jtry!(File.open(...)).read(...)).

So, I wonder if we could make the macros support any kind of Result<T, E> (or at least E: Display) and call .to_field_result() on the result automatically? Then we could maybe even remove the ResultExt trait and jtry! macro.

[srijs]

IIRC both the try macro as well as the ? operator provide type upcasting: https://github.com/rust-lang/rfcs/blob/master/text/0243-trait-based-exception-handling.md#exception-type-upcasting.

So an alternative could be to define a concrete type FieldError implementing From:

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 ? operator without to_field_result in field bodies:

field foo()  {
  let txn = db.transaction()?;
  ...
}

... as well as enable the use of try! instead of jtry!, meaning that both jtry and ResultExt could be deprecated.

[theduke]

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.

[theduke]

Both ResultExt and the jtry macro were removed in 0.9.