It was unclear that exception handling 'just works' about comlink HOT 7 CLOSED

from comlink.

I'd say it mostly works, but doesn't keep all information of the thrown object.

For example, I'm using PouchDB, which throws {status: 404}. I'm running a slightly patched comlink for a few months now that retains all enumerable properties and the error message and stack (if there is one):

--- a/node_modules/comlinkjs/comlink.js
+++ b/node_modules/comlinkjs/comlink.js
@@ -27,9 +27,9 @@ const proxyTransferHandler = {
 };
 const throwTransferHandler = {
     canHandle: (obj) => obj && obj[throwSymbol],
-    serialize: (obj) => obj.toString() + "\n" + obj.stack,
+    serialize: (obj) => Object.assign({}, obj, {message: obj.message, stack: obj.stack}),
     deserialize: (obj) => {
-        throw Error(obj);
+        throw Object.assign(new Error(), obj);
     }
 };
 export const transferHandlers = new Map([

from comlink.

@michael42 Good catch. You mind opening a PR? I just wanna be on the safe side legally — I don’t think I can just rip your code from your comment ;)

from comlink.

@PaulKinlan What kind of best practices are you looking for? The goal was for Comlink to behave as transparently as possible.

from comlink.

I know what the issue was now. You can't create a Symbol on a string, so when a library does throw 'sumfins wrong'; Comlink will throw an error like so Cannot create property 'Symbol(throw)' on string

from comlink.

Note that this won't work:

throw Object.assign(new Error(), obj);

if you have code like this:

} catch (error) {
  throw Object.assign(new Error('Something went wrong:' + err.message), { error })
}

because error will not be transferrable and throw when trying to post the message

from comlink.

This is now documented in the README.

from comlink.