[
https://issues.apache.org/jira/browse/THRIFT-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891298#comment-13891298
]
Jens Geyer edited comment on THRIFT-2343 at 2/4/14 10:30 PM:
-------------------------------------------------------------
Too quick. The tutorial and any other service containing methods without any
exception is broken:
{code}
shared\shared_service.go:178: v declared and not used
{code}
was (Author: jensg):
Too quick. The tutorial is broken:
{code}
shared\shared_service.go:178: v declared and not used
{code}
> Golang - Return a single error for all exceptions instead of multiple return
> values
> -----------------------------------------------------------------------------------
>
> Key: THRIFT-2343
> URL: https://issues.apache.org/jira/browse/THRIFT-2343
> Project: Thrift
> Issue Type: Improvement
> Components: Go - Compiler
> Affects Versions: 0.9.1
> Reporter: Chris Bannister
> Assignee: Jens Geyer
> Fix For: 0.9.2
>
> Attachments:
> 0001-Only-expose-returning-a-single-error-return-in-Go.patch,
> 0002-go-processor-exceptions-are-treated-as-one-error.patch
>
>
> Currently the Thrift compiler for Go generates some very ugly (by Go's
> standard) code for method calls. This is because of the fact that Go does not
> have exceptions.
> My proposal is to change the way the exceptions are handled in Go, instead of
> returning each exception explicitly as a return value, instead return the
> exceptions as a single error return. This has another benefit that Go servers
> will no longer be able to 'throw' multiple exceptions, previously you could
> assign an error to all the defined exceptions of a method which shouldn't be
> possible.
> This change relies on the fact that the exceptions generated by Thrift
> implement the Error interface, which they now do (in 0.9.2).
> It has the downside that the exceptions thrown to a client calling a thrift
> method are no longer immediately visible. But this is the same way the Go
> standard library handles it so it shouldn't be a problem.
> It changes the generated interface so it will break backwards compatibility,
> but as 0.9.2 is already breaking backwards compatibility this shouldn't be a
> huge problem, but should be considered.
> The proposed changes change the Processor methods for each method, doing a
> type switch against all the defined exceptions for the method. The
> fallthrough case is the same INTERNAL_SERVER_ERROR exception.
> Please consider this a RFC.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
