Hi @AnsisMalins,

StdString_New and StdString_Delete do not interact with V8 at all, they just create and destroy a std::string.

Technically, they create and destroy instances of ClearScript's internal StdString class 😊 But you're right, they don't interact with V8.

Is that really necessary to be wrapped in an InvokeNoThrow?

A few points:

1. All calls into native code are handled by the V8SplitProxyNative class, whose job is to route calls to the appropriate native assembly based on the runtime environment – e.g., ClearScriptV8.win-x86.dll, ClearScriptV8.linux-arm64.so, etc.
2. Because the StdString_ methods aren't expected to throw exceptions, we use InvokeNoThrow (as opposed to Invoke) to bypass some exception handling boilerplate.
3. Although it avoids exception handling, InvokeNoThrow still sets and restores the managed method table. That ensures that native code enters the right application domain when calling back to the host. As the StdString_ methods don't call back to the host, we could bypass that too, and in the next ClearScript release, we use the new method InvokeRaw to do just that.

Cheers!