callback handler implementation

[natebrennand]

So I've been trying to figure out what the best way to handle errors in the callback handlers, currently they're just ignored. There isn't really an accepted way of doing this based on the golang mailing list but one of the solutions is to return a struct that contains both an object and an error.

Any opposition to switching ours to that?

[natebrennand]

mailing list discussions:

• https://groups.google.com/forum/#!searchin/golang-nuts/channel$20error/golang-nuts/cTrBcyjqCxg/-wfVlTwkwV0J
• https://groups.google.com/forum/#!searchin/golang-nuts/channel$20error/golang-nuts/RYkAXrHsuqI/VoDHi6m6s-QJ

[chelpu]

Let's do it

[natebrennand]

k, will switch to return something along these lines:

type CallbackResponse struct {
    Callback
    Err error
}

If we embed it then it's still accessible with a single dot notation access

[natebrennand]

I thought about it more and I'm less sure that it's useful.
There are 2 core reasons that an error would occur.

1. Twilio messes up their encoding. Everything is fucked no matter what at this point. You can't re-request a callback to be sent
2. Someone is accidentally sending invalid requests to the endpoint

I think we should just import log and leave a message if it's every invalid

[chelpu]

Fine by me.