Improve error handling usability

[miere]

As discussed at #294, there's room for usability/design improvement on how internal errors are handled.

I believe it would be beneficial if we remove the requirement to rewrite our own Error alias for each lambda endpoint. By simply making the existing one public would solve this problem. It would also allow the maintainers to create their own backward compatible Error type, with little to (possibly) zero impact on users of this library.

[rimutaka]

@miere , I agree, but are you sure it will work? There was a discussion re this some time ago, if I recall it correctly. @softprops may remember the reason why it was done that way.

[softprops]

I was a fan of the type alias for the record :)

The pros outweigh the cons for me.

Pros

• concise while still flexible type api
• easier migration path for users if the type changes. Most won't need to change their code

Cons

• widens surface area (imports needed from this crate be ate lib)

There have been a few discussions in the past about using an external crate specific type. I try to stay clear for this because the rust ecosystem tends to change its taste for error crates every few years (error-chain, failure, anyhow, etc) which tends to become a maintenance burden for crates exporting those types. This end up breaking your api contracts by migrating your crate's error to the current trend. I do not enjoy this kind of work. I like the std library because it's by definition standard!

A type alias over std lib types seems like a happy medium for me

[coltonweaver]

I tried my hand at the suggestion in #298. Let me know if you have any feedback!

[coltonweaver]

I've merged that change in now. Gonna close this issue.