Handle any errors #26
Conversation
…ve ErrorReponse directly
…e to handle any error type
…ration to the new() function on the ErrorResponse
…+ Send + Sync + Debug. Updated samples to reflect this
| @@ -11,8 +11,10 @@ | |||
| //! extern crate serde_derive; | |||
| //! #[macro_use] | |||
| //! extern crate lambda_runtime; | |||
| //! #[macro_use] | |||
| //! extern crate simple_error; | |||
There was a problem hiding this comment.
I'm not sure how many people use simple_error. Should we opt for Failure for popularity reasons?
There was a problem hiding this comment.
As per our conversation, I'm keeping the simple error crate in the docs example for simplicity's sake. I've removed the #[macro_use] and added an example specific to the failure crate
| extern crate log; | ||
| extern crate serde_derive; | ||
| extern crate simple_logger; | ||
| #[macro_use] |
There was a problem hiding this comment.
We don't need to have #[macro_use] in Rust 1.30 and above—they can be imported like normal macros. Given that the 2018 edition is coming out on Thursday, I think it's a good idea to be forward-facing with regard to these imports.
There was a problem hiding this comment.
Fixed all over the place.
| /// The `HandlerError` struct can be use to abstract any `Err` of the handler method `Result`. | ||
| /// The `HandlerError` object can be generated `From` any object that supports `Display`, | ||
| /// `Send, `Sync`, and `Debug`. This allows handler functions to return any error using | ||
| /// the `?` syntax. For example `let _age_num: u8 = e.age.parse()?;` will return the |
There was a problem hiding this comment.
since this comment is likely going to be read from the perspective of someone reading the rustdoc without much context for the example this is lifted from in the repo, you may just want to give a more isolated example like "not a u8".parse::<u8>()?
|
wanted to give you a quick heads up about a pull that may conflict with this but it seems there are a number of merge conflicts already present. In any case, in #50, I'm proposing moving away from stringly values for ErrorResponse#errorType |
|
Closing this PR in favor of the refactor in #63 |
Issue #, if available: #23
Description of changes:
Beginning to address generic error handling in the runtime. Changed the handler to return a
Box<dyn Error>. This is still a work in progress.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.