[jira] [Assigned] (THRIFT-2932) Node.js Thrift connection libraries throw Exceptions into event emitter

["Randy Abernethy (JIRA)" <ji...@apache.org>]

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

Randy Abernethy reassigned THRIFT-2932:
---------------------------------------

    Assignee: Randy Abernethy

> 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
>         Attachments: 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)