Adds 'throw_' method to val

[robfors]

As mentioned in #6330.
Something like this will now work:

val::global("TypeError").new_(val("wrong type")).throw_();

In the tests found in test_val.cpp it can be seen that an error can be thrown in CPP and successfully caught in JS.

[kripken]

cc @chadaustin @Brion

[bvibber]

Looks good to me -- I think those CI test fails are just transitory failures of the browser-based tests.

[kripken]

Great, thanks @robfors and @Brion!

Yes, those errors are current random fails on CI - I'm working on fixing some of those now actually, hopefully it will get better soon.

[chadaustin]

I'll throw in my 👍 too. :)

I forget - do JavaScript exceptions thrown from C++ cause C++ destructors to unwind?

[kripken]

@chadaustin they should - calls become invokes, which catch any JS exception.

[tuananh]

@robfors do you have an example

i tried val::global("TypeError").new_("wrong type").throw_(); and got error

In file included from /emsdk_portable/sdk/system/include/emscripten/bind.h:21:
In file included from /emsdk_portable/sdk/system/include/emscripten/val.h:15:
/emsdk_portable/sdk/system/include/emscripten/wire.h:346:24: error: array 'new' cannot have initialization arguments
                return new T(v);
                       ^     ~
/emsdk_portable/sdk/system/include/emscripten/val.h:228:62: note: in instantiation of member function 'emscripten::internal::GenericBindingType<char [11]>::toWireType' requested here
            writeGenericWireType(cursor, BindingType<First>::toWireType(std::forward<First>(first)));
                                                             ^
/emsdk_portable/sdk/system/include/emscripten/val.h:236:17: note: in instantiation of function template specialization 'emscripten::internal::writeGenericWireTypes<char const (&)[11]>' requested here
                writeGenericWireTypes(cursor, std::forward<Args>(args)...);
                ^
/emsdk_portable/sdk/system/include/emscripten/val.h:548:35: note: in instantiation of member function 'emscripten::internal::WireTypePack<char const (&)[11]>::WireTypePack' requested here
            WireTypePack<Args...> argv(std::forward<Args>(args)...);
                                  ^
/emsdk_portable/sdk/system/include/emscripten/val.h:455:20: note: in instantiation of function template specialization 'emscripten::val::internalCall<emscripten::internal::_EM_VAL *(*)(emscripten::internal::_EM_VAL *, unsigned int, const void *const *, const void *), char const (&)[11]>' requested here
            return internalCall(internal::_emval_new,std::forward<Args>(args)...);
                   ^
src/camaro.cpp:397:30: note: in instantiation of function template specialization 'emscripten::val::new_<char const (&)[11]>' requested here
    val::global("TypeError").new_("wrong type").throw_();
                             ^
1 error generated.
shared:ERROR: compiler frontend failed to generate LLVM bitcode, halting

[robfors]

I fixed the mistake in my example. Thanks for pointing that out.

[tuananh]

@robfors

when i tried this

val::global("Error").new_(val("wrong type")).throw_();

I got

error: type 'string' (aka 'basic_string<char, char_traits<char>, allocator<char> >') does not provide a call operator
      val::global("Error").new_(val("wrong type")).throw_();
                                ^~~
1 error generated.

Sorry, I'm still kinda new to emcc

[robfors]

That is strange.
val("wrong type") should have worked without any problems. The only suggestion I am able to give is to make sure all the necessary libraries are included:

#include <stdio.h>
#include <iostream>
#include <emscripten/bind.h>
#include <emscripten/emscripten.h>
#include <emscripten/val.h>

If it helps at all, you can also refer to the tests for some examples. They can be run with python tests/runner.py test_embind_val.

[blazej-czapp]

Hi folks, I realise this is quite old, but from what I can tell, calls to throw_() from C++ don't cause destructors unwinding - objects in the same scope as the throw don't have their destructors called. Looking at the implementation, the actual throw happens in JS so C++ never realises it needs to unwind anything?

[blazej-czapp]

In fact, it seems the very throw statement might be leaking memory?

val::global("TypeError").new_(val("wrong type")).throw_();

creates a new object, the handle to which is stored in the val returned from new_() (never mind the val("wrong type"), this one is destroyed immediately). Then we call throw_() on that value:

    [[noreturn]] void throw_() const {
        internal::_emval_throw(handle);
    }

This already tells us that we're not coming back, but looking deeper, we have _emval_throw(), which throws the corresponding object in JavaScript (i.e. C++ isn't aware of this). Thus, from what I can tell, the destructor of the val is never called, so the reference count of the JS object it represents isn't decremented, resulting in a memory leak?