[ 
https://issues.apache.org/jira/browse/THRIFT-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14291343#comment-14291343
 ] 

Andrew de Andrade commented on THRIFT-2932:
-------------------------------------------

+1 On knowing more about this as well. 

I'm about to start work on using the Thrift JavaScript client in the browser, 
and would like to know about the history of the JavaScript code. I'm especially 
curious to know why there isn't more code sharing between the js node thrift 
libraries and the js browser thrift library. 


> Node.js Thrift connection libraries throw Exceptions into event emitter
> -----------------------------------------------------------------------
>
>                 Key: THRIFT-2932
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2932
>             Project: Thrift
>          Issue Type: Bug
>          Components: Node.js - Library
>    Affects Versions: 0.9.2
>            Reporter: Tom Croucher
>            Priority: Critical
>
> I've been investigating using the Node.js client in a project however it 
> seems like there are instances which don't follow Node.js best practices. 
> In particular http_connection.js and connection.js throw errors during 
> callbacks. This is considered an anti-pattern in Node because it both removes 
> the Exception from the context of the callback making it hard to associate 
> with a request as well as throwing it in the context of the EventEmitter code 
> which can cause inconsistencies in the Node process.
> This means under some error conditions an uncaught exception would be thrown 
> or at least an 'error' event on the singleton client (again removing it from 
> the request context).
> Both transport receivers share the same copy-pasta code which contains:
> {code:javascript}
>     catch (e) {
>       if (e instanceof ttransport.InputBufferUnderrunError) {
>         transport_with_data.rollbackPosition();
>       }
>       else {
>         throw e;
>       }
>     }
> {code}
> I'm working on a patch, but I'm curious about some of the history of the 
> code. In particular the exception based loop flow control and the using the 
> seqid to track the callback which makes it hard to properly associate it with 
> exception handling.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to