[ 
https://issues.apache.org/jira/browse/THRIFT-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-2932.
-------------------------------------
       Resolution: Fixed
    Fix Version/s: 0.9.3

Seems like future progress in this area is carrying on in other tickets. I am 
resolving this one as fixed. Please reopen if we need to revisit things.

> 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
>            Assignee: Randy Abernethy
>            Priority: Critical
>             Fix For: 0.9.3
>
>         Attachments: 0001-minor-node-http-connection-clean-up.patch, 
> 0001-nodejs-exceptions-to-callbacks-instead-of-throws-int.patch
>
>
> 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