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

encoding/gob: handle errors #3353

Closed
alberts opened this issue Mar 19, 2012 · 19 comments
Closed

encoding/gob: handle errors #3353

alberts opened this issue Mar 19, 2012 · 19 comments

Comments

@alberts
Copy link
Contributor

alberts commented Mar 19, 2012

What steps will reproduce the problem?

gob.Register(errors.New("")) returns gob: type errors.errorString has no
exported fields

Please provide any additional information below.

https://groups.google.com/forum/?fromgroups#!topic/golang-dev/Cua1Av1J8Nc
@dsymonds
Copy link
Contributor

Comment 1:

http://golang.org/cl/5844059 is ready for post-Go 1.

Labels changed: added priority-later, removed priority-triage.

Owner changed to @dsymonds.

Status changed to Started.

@alberts
Copy link
Contributor Author

alberts commented Mar 19, 2012

Comment 2:

After thinking about it more, registering error types with gob is probably an endless
black pit of despair, so we probably don't want to unduly enable anyone that wants to go
down it.

@robpike
Copy link
Contributor

robpike commented Mar 19, 2012

Comment 3:

Since error is a predeclared type, prima facie it doesn't seem unreasonable to support
them in gob directly. It would be easy to send a string and call errors.New(s) on the
receiving side. It may even be possible to do better, like ask if the type can GobEncode
itself first.
Worth thinking about and addressing carefully, if at all. GobEncode in the errors
package is not the answer.

@alberts
Copy link
Contributor Author

alberts commented Mar 28, 2012

Comment 4:

One additional issue to think about carefully is whether things like Temporary and
Timeout should work on both sides of the connection.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 5:

Labels changed: added go1.1maybe.

@rsc
Copy link
Contributor

rsc commented Sep 14, 2012

Comment 6:

Removing 'Started' and renaming summary, since we've established that the errors package
is not where we want to make the change, if anywhere.

Owner changed to ---.

Status changed to Accepted.

@robpike
Copy link
Contributor

robpike commented Mar 7, 2013

Comment 7:

Labels changed: removed go1.1maybe.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 8:

Labels changed: added go1.2maybe.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 9:

Labels changed: added feature.

@robpike
Copy link
Contributor

robpike commented Aug 15, 2013

Comment 10:

Too scary to do this close to release. Plan for 1.3.

Labels changed: added go1.3, removed go1.2maybe.

@robpike
Copy link
Contributor

robpike commented Aug 20, 2013

Comment 11:

Labels changed: removed go1.3.

@rsc
Copy link
Contributor

rsc commented Oct 18, 2013

Comment 12:

Issue #6467 has been merged into this issue.

@robpike
Copy link
Contributor

robpike commented Oct 18, 2013

Comment 13:

I don't see the relationship between 6467 and this bug (3353). The newer one is just
asking for a wording change in a message; this one is asking for a change in how errors
are transcoded.

@rsc
Copy link
Contributor

rsc commented Oct 18, 2013

Comment 14:

Unmerged, sorry. I was reading quickly and misunderstood the subject.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 15:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 16:

Labels changed: removed feature.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 17:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 18:

Labels changed: added repo-main.

@agnivade
Copy link
Contributor

agnivade commented Nov 5, 2018

Duplicate of #23340.

@agnivade agnivade closed this as completed Nov 5, 2018
@golang golang locked and limited conversation to collaborators Nov 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants