Add logic to handle graceful error handling when primitive errors are thrown by JS functions #1075

JckXia · 2021-09-21T02:17:08Z

Added some logic to override Value() function on the Error object to do the unwrapping, as well wrapping logic to the Object(env, value) function accordingly.

mhdawson · 2021-09-21T14:12:53Z

napi-inl.h

+  // We are checking if the object is wrapped
+  bool isWrappedObject = false;
+  napi_has_property(
+      _env, refValue, String::From(_env, "isWrapObject"), &isWrappedObject);


I think we likely want to make the "isWrapObject" more unique to avoid potential collision with user code. Maybe use a GUID with -isWrappedObject tacked on to the end?

mhdawson · 2021-09-21T14:15:07Z

doc/error_handling.md

@@ -14,6 +14,10 @@ If C++ exceptions are enabled (for more info see: [Setup](setup.md)), then the
 `Napi::Error` class extends `std::exception` and enables integrated
 error-handling for C++ exceptions and JavaScript exceptions.

+Note, that due to limitations of the N-API, if one attempt to cast the error object thrown as a primitive, an


Suggested change

Note, that due to limitations of the N-API, if one attempt to cast the error object thrown as a primitive, an

Note, that due to limitations of the N-API, if one attempts to cast the error object thrown as a primitive, an

mhdawson · 2021-09-21T14:16:46Z

doc/error_handling.md

@@ -14,6 +14,10 @@ If C++ exceptions are enabled (for more info see: [Setup](setup.md)), then the
 `Napi::Error` class extends `std::exception` and enables integrated
 error-handling for C++ exceptions and JavaScript exceptions.

+Note, that due to limitations of the N-API, if one attempt to cast the error object thrown as a primitive, an
+wrapped object will be received instead. (With properties ```isWrapObject``` and ```errorVal``` containing the primitive value thrown)


Maybe just add some additional clarification that this is when the node-addon-api Error C++ object is used within the addon.

mhdawson · 2021-09-21T14:25:22Z

napi-inl.h

    // Avoid infinite recursion in the failure case.
    // Don't try to construct & throw another Error instance.
    NAPI_FATAL_IF_FAILED(status, "Error::Error", "napi_create_reference");
  }
 }

+inline Object Error::Value() const {


I think it might make sense for this to return Value instead of Object (Values can be objects), the main concern is that would potentially be breaking.

The reason is that we wrapping so that we can have a value versus just objects. If its possible we might want two methods one which returns a Value and one which returns an Object in order to avoid breaking existing code.

I tried setting the return type to Value and it seems to pass all the test suites. Although I am not too sure if that breaks any conventions. (i.e, In the base Reference class, Reference<T>::Value() will return an instance of type T, and Error is of type Object since it inherits ObjectReference, which it self inherits from Reference<Object>. Therefore people might expect Error::Value() to return an Object also)

For the second part then, can I declare two public methods Napi::Value GetUnWrappedValue() and Object Value() ?

If is possible to have 2 methods both called Value() which return different types. If so that might make sense assuming the compiler will select the most appropriate one based on how you use the return value?

Hmm, I am not too sure if it's possible to overload base on return value in C++ (without using templates) according to this post (https://stackoverflow.com/questions/9568852/overloading-by-return-type).

After discussing in Node-API team meeting I think this is ok as is.

mhdawson

LGTM

NickNaso

Just some notes about documentation.

NickNaso · 2021-09-30T15:59:43Z

doc/error_handling.md

@@ -14,6 +14,10 @@ If C++ exceptions are enabled (for more info see: [Setup](setup.md)), then the
 `Napi::Error` class extends `std::exception` and enables integrated
 error-handling for C++ exceptions and JavaScript exceptions.

+Note, that due to limitations of the N-API, if one attempts to cast the error object wrapping a primitive inside a C++ addon, the wrapped object


Node-API instead of N-API

NickNaso · 2021-09-30T16:01:05Z

doc/error_handling.md

@@ -14,6 +14,10 @@ If C++ exceptions are enabled (for more info see: [Setup](setup.md)), then the
 `Napi::Error` class extends `std::exception` and enables integrated
 error-handling for C++ exceptions and JavaScript exceptions.

+Note, that due to limitations of the N-API, if one attempts to cast the error object wrapping a primitive inside a C++ addon, the wrapped object
+will be received instead. (With properties ```4b3d96fd-fb87-4951-a979-eb4f9d2f2ce9-isWrapObject``` and ```errorVal``` containing the primitive value thrown)


It's inline code so please use one back tick es. 4b3d96fd-fb87-4951-a979-eb4f9d2f2ce9-isWrapObject

doc/error_handling.md

napi-inl.h

gabrielschulhof · 2021-10-01T15:28:01Z

napi-inl.h

+
+  // We are checking if the object is wrapped
+  bool isWrappedObject = false;
+  napi_has_property(


Maybe add a typecheck first to see that it's not a Symbol. If the reference is a Symbol it's definitely not wrapped. In new Node.js versions, the reference can be a symbol.

Done. Though do we need to consider the cases where people are using an older Node.js version?

gabrielschulhof · 2021-10-01T15:29:03Z

napi.h

@@ -8,7 +8,6 @@
 #include <mutex>
 #include <string>
 #include <vector>
-


This line should remain.

gabrielschulhof · 2021-10-01T15:31:12Z

test/binding.cc

@@ -31,6 +31,7 @@ Object InitDate(Env env);
 Object InitDataView(Env env);
 Object InitDataViewReadWrite(Env env);
 Object InitEnvCleanup(Env env);
+Object InitErrorHandlingPrim(Env env);


Are these names consistent with the file names being used? This will help @deepakrkris with the unit test filtering.

@deepakrkris can you double-check this please?

gabrielschulhof · 2021-10-01T15:32:23Z

test/errorHandlingForPrimitives.cc

+  Napi::Object exports = Napi::Object::New(env);
+  exports.Set("errorHandlingPrim", Napi::Function::New<Test>(env));
+  return exports;
+}


Please add a newline to the end of the file!

KevinEady

See comments

KevinEady · 2021-10-22T14:27:51Z

napi-inl.h

+      status = napi_set_property(env,
+                                 wrappedErrorObj,
+                                 String::From(env, "errorVal"),
+                                 Value::From(env, value));
+      NAPI_FATAL_IF_FAILED(status, "Error::Error", "napi_set_property");
+
+      status = napi_set_property(


IIRC using napi_set_property will allow the property to be enumerable and writable. Maybe we should use napi_define_properties and make the property read-only? What about enumerable?

KevinEady · 2021-10-22T14:29:30Z

napi-inl.h

+          env,
+          wrappedErrorObj,
+          String::From(env,
+                       "4b3d96fd-fb87-4951-a979-eb4f9d2f2ce9-isWrapObject"),


This magic-value, can we make as some constant? Maybe a private static const on Error class? Thoughts?

@devsnek 's suggestion is better: use a symbol instead of this string.

Hey @KevinEady. I updated my PR to opt using symbol instead of this magic string but ran into some issues.

In particular, when I ran the tests, the test/error_terminating_environment.js suite will crash consistently. (By this command test(`./build/${buildType}/binding_swallowexcept.node`, false);. Looking at the code I am assuming it is saying that by running the tests in this configuration, the process shouldn't crash but be handled gracefully.

However, when I extract the error message from the spawnSync call, it looks like somewhere, an Error instance was thrown and crashed the app, but I can't quite pinpoint where exactly.

After doing some debugging, all I can find is that if I remove the binding.error.waitForWorkerThread() function statement on line 32 of the error_terminating_environment.js file, no Error is thrown but I am not quite sure if the tests are ran either. Any ideas on why this might be happening? Thanks!

devsnek · 2021-10-22T14:30:57Z

napi-inl.h

+          env,
+          wrappedErrorObj,
+          String::From(env,
+                       "4b3d96fd-fb87-4951-a979-eb4f9d2f2ce9-isWrapObject"),


can a symbol not be used here? seems like the perfect use case.

…imitations with this impl

mhdawson · 2021-10-29T15:12:01Z

napi-inl.h

-        String::From(_env, "4b3d96fd-fb87-4951-a979-eb4f9d2f2ce9-isWrapObject"),
-        &isWrappedObject);
+
+    MaybeOrValue<Symbol> result = Symbol::For(_env, "isWrapObject");


One suggestion is maybe we should still use a GUID here instead of the string.

gabrielschulhof · 2021-11-12T16:19:51Z

napi-inl.h

+
+      napi_property_descriptor errValDesc = {
+          "errorVal",                     // const char* utf8Name
+          String::From(env, "errorVal"),  //  napi_value name


This can be nullptr. utf8name is sufficient for specifying the name of the property.

gabrielschulhof · 2021-11-12T16:22:28Z

napi-inl.h

+                                              nullptr};
+
+#ifdef NODE_ADDON_API_ENABLE_MAYBE
+      Symbol uniqueSymb;


Move this declaration outside the #ifdef.

gabrielschulhof · 2021-11-12T16:23:00Z

napi-inl.h

+      NAPI_FATAL_IF_FAILED(status, "Error::Error", "napi_define_properties");
+#else
+
+      wrapObjFlag.name = result;


Suggested change

wrapObjFlag.name = result;

uniqueSymb = result;

wrapObjFlag.name = result;

gabrielschulhof · 2021-11-12T16:24:08Z

napi-inl.h

+      status = napi_define_properties(env, wrappedErrorObj, 1, &wrapObjFlag);
+      NAPI_FATAL_IF_FAILED(status, "Error::Error", "napi_define_properties");


Move these two statements below the #endif. That way, you are not duplicating them in both bodies of the #if...#else...#endif, thereby reducing the size of the the #if...#else...#endif block.

gabrielschulhof · 2021-11-12T16:24:39Z

napi-inl.h

+      status = napi_define_properties(env, wrappedErrorObj, 1, &wrapObjFlag);
+      NAPI_FATAL_IF_FAILED(status, "Error::Error", "napi_define_properties");


Remove these two lines.

gabrielschulhof · 2021-11-12T16:49:53Z

napi-inl.h

+    // We are checking if the object is wrapped
+    bool isWrappedObject = false;
+
+    MaybeOrValue<Symbol> result = Symbol::For(_env, "isWrapObject");


Should this also be guarded by #ifdef NODE_ADDON_API_ENABLE_MAYBE since it's MaybeOrValue<Symbol>?

gabrielschulhof · 2021-11-12T16:51:22Z

napi-inl.h

+    if (result.IsJust()) {
+      uniqueSymb = result.Unwrap();
+    }
+    status = napi_has_property(_env, refValue, uniqueSymb, &isWrappedObject);


Please use the same pattern here as I mentioned before. Move Symbol uniqueSymb outside the #ifdef ... #else ... #endif block and place the common code after the block so you don't have to write it twice.

JckXia · 2021-11-14T22:33:56Z

@mhdawson @gabrielschulhof @KevinEady @NickNaso Hello everyone. I updated this pull request to opt using hard-coded strings as the property key on the error object, due to issues that came with using Symbol::For. Thanks!

mhdawson · 2021-11-16T21:41:58Z

@mhdawson @gabrielschulhof @KevinEady @NickNaso do you want to take a look before I land this, if so let me know before the end of the week. If I don't get an ask for more time to review I'll go ahead and land on Friday.

mhdawson · 2021-11-16T21:44:58Z

@JckXia I see one comment from @gabrielschulhof that I don't think you addressed the one about lines 2620 and 2621

JckXia · 2021-11-16T22:00:33Z

@mhdawson I believe Gabriel's comment originally was addressing the fact that I was using a separate flag to denote the error object is wrapped on top of having an errorVal property. I removed one of the property descriptors and now we only attach one property 4bda9e7e-4913-4dbc-95de-891cbf66598e-errorVal to show that the err obj is wrapped

e0567d0

mhdawson · 2021-11-16T22:09:05Z

@JckXia thanks for the clarification.

JckXia · 2021-11-22T15:59:42Z

Hey guys @mhdawson @gabrielschulhof @NickNaso @KevinEady. Could you take a look at this PR again? Thanks!

mhdawson

LGTM, looks good to me with all the update. @JckXia thanks for your work on this.

KevinEady

LGTM! Thank you for clarifying the need for the string key in today's Node.JS API meeting.

JckXia · 2021-11-26T16:51:47Z

Landed as 293c732

JckXia mentioned this pull request Sep 21, 2021

Napi::Env::GetAndClearPendingException assumes exceptions are Error objects #912

Closed

mhdawson reviewed Sep 21, 2021

View reviewed changes

mhdawson mentioned this pull request Sep 24, 2021

[BUG] node REPL crashes creating ObjectWrap in getter #1000

Closed

mhdawson approved these changes Sep 28, 2021

View reviewed changes

NickNaso reviewed Sep 30, 2021

View reviewed changes

gabrielschulhof reviewed Oct 1, 2021

View reviewed changes

JckXia force-pushed the handle-error-thrown branch from c0b2584 to 17bff94 Compare October 21, 2021 20:11

KevinEady reviewed Oct 22, 2021

View reviewed changes

devsnek reviewed Oct 22, 2021

View reviewed changes

JckXia added 5 commits October 23, 2021 18:58

Added unwrapping logic to handle graceful error handling for primitives

ed4d1c5

Remove un-necessary comment/iostream and updated docs to reflect on l…

c89f0bf

…imitations with this impl

Update doc and appending GUID to object property

02bcfbc

Update PR based on review comments

173c5bc

Replace magic value with symbol

a0b3fe9

JckXia force-pushed the handle-error-thrown branch from 17bff94 to a0b3fe9 Compare October 24, 2021 16:30

mhdawson reviewed Oct 29, 2021

View reviewed changes

gabrielschulhof reviewed Nov 12, 2021

View reviewed changes

JckXia added 2 commits November 14, 2021 17:21

Refactor code. Using hard coded string instead of using symbol

6918138

Update documents

e0567d0

mhdawson approved these changes Nov 22, 2021

View reviewed changes

KevinEady approved these changes Nov 26, 2021

View reviewed changes

JckXia merged commit 293c732 into nodejs:main Nov 26, 2021

JckXia deleted the handle-error-thrown branch December 14, 2022 00:46

	Note, that due to limitations of the N-API, if one attempt to cast the error object thrown as a primitive, an
	Note, that due to limitations of the N-API, if one attempts to cast the error object thrown as a primitive, an

	wrapObjFlag.name = result;
	uniqueSymb = result;
	wrapObjFlag.name = result;

		status = napi_define_properties(env, wrappedErrorObj, 1, &wrapObjFlag);
		NAPI_FATAL_IF_FAILED(status, "Error::Error", "napi_define_properties");

Add logic to handle graceful error handling when primitive errors are thrown by JS functions #1075

Add logic to handle graceful error handling when primitive errors are thrown by JS functions #1075

Conversation

JckXia commented Sep 21, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JckXia Sep 21, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mhdawson left a comment

Choose a reason for hiding this comment

NickNaso left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KevinEady left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JckXia commented Nov 14, 2021

mhdawson commented Nov 16, 2021

mhdawson commented Nov 16, 2021

JckXia commented Nov 16, 2021 • edited Loading

mhdawson commented Nov 16, 2021

JckXia commented Nov 22, 2021

mhdawson left a comment

Choose a reason for hiding this comment

KevinEady left a comment

Choose a reason for hiding this comment

JckXia commented Nov 26, 2021

JckXia Sep 21, 2021 •

edited

Loading

JckXia commented Nov 16, 2021 •

edited

Loading