lambda: check if error type is InvokeResponse_Error

[smasher164]

Currently, we cannot set the errorType field without creating a custom
named error type. This causes a proliferation of dummy named error types
whose only purpose is to set a text field, and limits the errorType
field to what can be expressed as an identifier.

This change checks that the panicked or returned error is if type
InvokeResponse_Error, and if so, uses it directly in the invoker's
response. InvokeResponse_Error is now updated to implement error.

Note: This is fully backwards compatible, since InvokeResponse_Error
previously did not implement the error interface.

Fixes #308.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov-commenter]

Codecov Report

Merging #312 into master will decrease coverage by 0.40%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #312      +/-   ##
==========================================
- Coverage   72.63%   72.23%   -0.41%     
==========================================
  Files          18       18              
  Lines         720      724       +4     
==========================================
  Hits          523      523              
- Misses        134      136       +2     
- Partials       63       65       +2     

Impacted Files	Coverage Δ
lambda/errors.go	77.27% <0.00%> (-17.18%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4145757...c7abb62. Read the comment docs.

[bmoffatt]

Thanks for the PR @smasher164 - Until now, I've considered the types in the messages package to be an internal implementations detail, but that's not a strongly held opinion.

I've forwarded this to the team to check for alternative approaches to the problem.

[smasher164]

Hey @bmoffatt, friendly ping to ask if there's any word on the issue/PR?
I have a couple of ideas on alternative approaches:

• The exported type does not have to be from the messages package. You can introduce and detect another named type. For instance, you could introduce something like this in the lambda package:

type Error struct{
    Message string `json:"errorMessage"`		
    Type    string `json:"errorType"`
}

• Introduce an interface that the user's desired error type could satisfy. This would be an optional interface that would require a type assertion, like:

type Error interface {
    error
    Type() string
}

The disadvantage is that the second option is a potentially breaking change, if the user's error implements the Type method.

[bmoffatt]

I talked with the team, and we figured that if we ever want to get rid of the messages library, we'd have to do a v2 release regardless of your initial proposal. I'll merge the change as-is

The lambda.Error change you proposed is cosmetically nicer, but I don't like that we'd just be introducing more types just to end up copying into InvokeResponse_Error anyways.