[
https://issues.apache.org/jira/browse/THRIFT-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823384#comment-15823384
]
ASF GitHub Bot commented on THRIFT-4011:
----------------------------------------
Github user Jens-G commented on the issue:
https://github.com/apache/thrift/pull/1156
Oopsie. After I read the word "map" above I must have been mentally
switched to maps somehow. My mistake.
Nevertheless what I said about panic and errors in general above still
holds true. At this time we have exactly 0 (zero) panics in the code under
/lib/go/thrift. So I would argue that introducing a panic at least breaks the
usual patterns of that library.
> Speaking of which, panicking in case of programmer error is very common
and idiomatic in Go. The standard library is full of such panics
Put four Go experts together and you get five opinions, all idiomatic.
Especially about the high and lofty Go error handling design principles:
> In Go, error handling is important. **The language's design and
conventions encourage you to explicitly check for errors** where they occur (as
distinct from the convention in other languages of throwing exceptions and
sometimes catching them).
Or mostly assigning them to `_` as many people do in Go. That's for the
"encourage you to explicitly check for errors" part. In contrast, an exception
must be caught, not only "sometimes", because there is no other error handling
option.
> The decision to not include exceptions in Go is an example of its
**simplicity** and orthogonality. Using multiple return values and a simple
convention, **Go solves the problem** of letting programmers know when things
have gone wrong and **reserves panic for the truly exceptional**.
I can't see any "simplicity" in replacing exceptions by panics,
"encouraging" error handling by leading people into misusing the `_` operator
and at the same time claiming "*this time, we get it right*". Go's error
handling is FUBAR from the beginning to the end. Good intentions, absolutely,
but the implementation .... All personal opinion, of course,
> Sets of Thrift structs generate Go code that can't be serialized to JSON
> ------------------------------------------------------------------------
>
> Key: THRIFT-4011
> URL: https://issues.apache.org/jira/browse/THRIFT-4011
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
> Reporter: Can Celasun
>
> Consider the following structs:
> {code}
> struct Foo {
> 1: optional string foo
> }
> struct Bar {
> 1: optional set<Foo> foos
> }
> {code}
> This compiles into the following Go code:
> {code}
> type Bar struct {
> Foos map[*Foo]struct{} `thrift:"foos,1" db:"foos" json:"foos,omitempty"`
> }
> {code}
> Even though the generated code has tags for JSON support, Bar can't be
> serialized to JSON:
> {code}
> json: unsupported type: map[*Foo]struct {}
> {code}
> One solution would be to use slices, not maps, for Thrift sets. Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
