[
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)