Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds WriteError func for writing Twirp errors to http.ResponseWriter #192

Merged
merged 2 commits into from Nov 6, 2019

Conversation

@mfridman
Copy link
Contributor

mfridman commented Nov 1, 2019

Fixes #186 #161

This changeset copies the twirp service implementation of WriteError to the core twitchtv/twirp package.

Note, all mention of "hooks" and underlying use of context has been removed.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

mfridman added 2 commits Nov 1, 2019
Copy link
Member

spenczar left a comment

At last! Thanks for doing this.

@spenczar spenczar merged commit 08383d1 into twitchtv:master Nov 6, 2019
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@mfridman mfridman deleted the mfridman:add_writeerr branch Nov 7, 2019
//
// Silently ignoring the error is our least-bad option. It's highly
// likely that the connection is broken and the original 'err' says
// so anyway.

This comment has been minimized.

Copy link
@ofpiyush

ofpiyush Nov 9, 2019

or return the error to the caller and let them log/ignore?

This comment has been minimized.

Copy link
@spenczar

spenczar Nov 26, 2019

Member

Ah! You're completely right that this is a very different situation from the generated code. This should most certainly be able to return an error.

It's unfortunate that this would be a breaking change and require a major version bump. This is why public API is hard. Ouch.

This comment has been minimized.

Copy link
@mfridman

mfridman Nov 26, 2019

Author Contributor

Indeed this could return an error, and probably should within this pkg.

But on the flip-side, it would no longer be a drop-in replacement to the generated version of WriteError.

In our case we were importing stub packages in various places outside the twirp stack, so it made sense to have it this way.

But it wouldn't be too hard to refactor with the returned error (we'd probably drop it anyways).

Maybe in a v6 we could add a returned error, or in v5 add a new function that returns the underlying error.

This comment has been minimized.

Copy link
@ofpiyush

ofpiyush Nov 28, 2019

It would technically break the public API, but would not do so in a code-breaking way.

Since this function doesn't return anything, all existing code would look like

twirp.WriteError(resp, err)

This would not break if you started returning errors. i.e. you can get away with adding it in a minor version.

If that feels too close to the edge of the dark side.

v5 add a new function that returns the underlying error.

💯
I do not claim to know how to cleanly fix a public API. Probably something like this work?

  • Add another method to return error
  • Mark the current one deprecated
  • In V6, drop the current method

This comment has been minimized.

Copy link
@spenczar

spenczar Dec 2, 2019

Member

I like this discussion - let's move it to an issue though, since I don't think anybody else is seeing this :) @ofpiyush, can you make an issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.