Stream's api methods must never throw - handling errors in DecodeStream, EncodeStream#81
Stream's api methods must never throw - handling errors in DecodeStream, EncodeStream#81royaltm wants to merge 1 commit intokawanet:masterfrom
Conversation
DarrenCook
left a comment
There was a problem hiding this comment.
Works for me.
The before code uses if(callback)..., but the after code does not. Should that be added, just in case? Or is callback guaranteed to always be a callable object when working with streams?
|
AFAIK the callback is guaranteed and mandatory in node's stream api: https://nodejs.org/dist/latest-v8.x/docs/api/stream.html#stream_transform_transform_chunk_encoding_callback |
|
Thanks for the patch and the approval comment. |
|
@kawanet Is it possible to merge this now? The Travis failure appears to be unrelated. I.e. all pull requests are failing at the same point (something to do with IE10?) |
|
@kawanet Ping? |
|
pong |
Hello there!
This is just a quick fix for #75.
Nodejs stream api is callback based and doesn't handle errors thrown inside api methods.
I've just wrapped in try/catch block implementation of Transform stream in DecodeStream and EncodeStream to handle errors according to stream specs. It's rather mandatory to be able to handle errors when working with streams. In current version of msgpack-lite node process dies due to unhandled error when such error occures: e.g. DecodeStream fed with garbage data or EncodeStream with circular references.
Test cases included.