Exception catching is too aggressive

[geremih]

In the current implementation, any exception thrown by a field-resolver is caught by execute and only the message is passed through. I had to checkout the repo and remove all the catch statement to find the issue in my code. Would it be possible to have an option to toggle the verbosity of the errors, or whether to throw them or not?

The error in my case was because the keys in the variables I was passing in were strings and lacinia was expecting keywords, which led to NullPointer exceptions down the line.

[hlship]

What I'm personally hoping to avoid is having to hook in a logging library. We could put more of the exception data into the error map, but that ends up being too verbose, and somewhat insecure (leaking implementation details to an unknown client). I don't think I like the idea of an exception callback, so that loops me back to logging.

[geremih]

@hlship
What's the reason behind not liking exception callbacks? It allows the user to specify how to handle exceptions and at the same time lets lacinia return errors that conform to the spec.
Cheaper alternatives would be to not catch the exceptions and have the user handle it along with spec compliance. Also, implementation details are already being leaked in the form of exception messages (less insecure than a full blown trace, but still).

[hlship]

Maybe something like an exception sanitizer callback that could be passed some information about where the exception occured, and the real exception, and is expected to return an error map.