You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on an implementation of the standard 'fetch' API for QuickJS. Like many other JS APIs,fetch uses optional arguments. It would therefore be helpful if the code in quickjspp.hpp that unwraps JS arguments for C++ functions could tolerate undefined/optional values rather than throwing an exception, e.g. something like this:
@@ -568,7 +568,5 @@
{
if (size_t(argc) <= I) {
- JS_ThrowTypeError(ctx, "Expected at least %lu arguments but received %d",
- (unsigned long)NArgs, argc);
- throw exception{ctx};
+ return js_traits<std::decay_t<T>>::unwrap(ctx, JS_UNDEFINED);
}
return js_traits<std::decay_t<T>>::unwrap(ctx, argv[I]);
I.e. the type T can be a std::optional or some other type whose js_traits can convert to and from 'undefined'.
Would this be a good idea? What have I not thought of?
The text was updated successfully, but these errors were encountered:
I'm working on an implementation of the standard 'fetch' API for QuickJS. Like many other JS APIs,
fetch
uses optional arguments. It would therefore be helpful if the code inquickjspp.hpp
that unwraps JS arguments for C++ functions could tolerate undefined/optional values rather than throwing an exception, e.g. something like this:I.e. the type
T
can be astd::optional
or some other type whosejs_traits
can convert to and from 'undefined'.Would this be a good idea? What have I not thought of?
The text was updated successfully, but these errors were encountered: