[
https://issues.apache.org/jira/browse/THRIFT-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14225330#comment-14225330
]
Chi Vinh Le edited comment on THRIFT-2854 at 11/25/14 11:00 PM:
----------------------------------------------------------------
Just asking :-)
I saw that part of code, but I considered it correct.
When reading the struct fails, the incoming stream is usually corrupted or not
available.
Good chance that the outgoing stream is not available as well.
{{iprot.ReadMessageEnd()}} will usually fail as a subsequent error and should
be considered as best effort try.
I see the same for sending the {{thrift.Exception}} as an best effort try. At
most we can log the errors that happen during those best effort tries.
The first error that occurred will be returned, which is more important than
the other errors – as they probably are subsequent errors caused by the first
one.
Anyway this is going off scope of the ticket. If the {{Process}} error handling
still bugs someone, he/she should open a ticket.
Back to main ticket:
I will implement the proposed solution for the problem mentioned in the ticket
by tomorrow. If anyone has a better solution please write here. This removes
the single problem I encountered to implement a faul tolerant Thrift server.
was (Author: cvlchinet):
Just asking :-)
I saw that part of code, but I considered it correct.
When reading the struct fails, the incoming stream is usually corrupted or not
available.
Good chance that the outgoing stream is not available as well.
{{iprot.ReadMessageEnd()}} will usually fail as a subsequent error and should
be considered as best effort try.
I see the same for sending the {{thrift.Exception}} as an best effort try. At
most we can log the errors that happen during those best effort tries.
The first error that occurs will be returned, which is more important than the
other errors – as they probably are subsequent error caused by the first one.
Anyway this is going off scope of the ticket. If the {{Process}} error handling
still bugs someone, he/she should open a ticket.
Back to main ticket:
I will implement the proposed solution for the problem mentioned in the ticket
by tomorrow. If anyone has a better solution please write here. This removes
the single problem I encountered to implemented a faul tolerant Thrift server.
> Go Struct writer and reader looses important error information
> --------------------------------------------------------------
>
> Key: THRIFT-2854
> URL: https://issues.apache.org/jira/browse/THRIFT-2854
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
> Affects Versions: 0.9.2
> Reporter: Chi Vinh Le
> Fix For: 0.9.3
>
>
> The GO Compiler generates code for a struct so that the following occurs:
> When an error occurs while reading or writing, a new error is created with
> additional text information using {code}fmt.Errorf{code}.
> By doing this the original error is completely lost. This is a real problem
> because errors of type TTransportException and TProtocolExceptions which
> contain additional information are lost. This will cause bad error handling,
> as the server implementation is dependent on those information.
> In my personal fork, I have a quick'n dirty fix for this, but I'm looking for
> a better option.
> Maybe instead of {code}fmt.Errorf{code} we could use this:
> {code}
> // Prepends additional information to an error without losing the Thrift
> interface
> func PrependError(err error, prepend string) error {
> if t, ok := err.(TTransportException); ok {
> return NewTTransportException(t.TypeId(), prepend+t.Error())
> }
> if t, ok := err.(TProtocolException); ok {
> return NewTProtocolExceptionWithType(t.TypeId(),
> errors.New(prepend+err.Error()))
> }
> if t, ok := err.(TApplicationException); ok {
> return NewTApplicationException(t.TypeId(), prepend+t.Error())
> }
> return errors.New(prepend + err.Error())
> }
> {code}
> I want to discuss this first here, because making a patch is quiet some work
> and I don't want major changes after I create a fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
