[ https://issues.apache.org/jira/browse/THRIFT-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew de Andrade updated THRIFT-2932: -------------------------------------- Comment: was deleted (was: More patches from Tom related to this cleanup around callbacks, errors and exceptions. ) > 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 > 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)