Questions regarding Javascript Engine error

Question

I have a question regarding Javascript engine error. This might be a very specific question, is there anyone saw this error before? Would you please help take a look?

Here is the error message:

483e709e1e8:buildDirARNJavaScriptEngine mac$ make install
Scanning dependencies of target JavaScriptEngine
[  8%] Building CXX object JavaScriptEngineImpl/src/CMakeFiles/JavaScriptEngine.dir/JavaScriptEngineImpl.cpp.o
[ 16%] Building CXX object JavaScriptEngineImpl/src/CMakeFiles/JavaScriptEngine.dir/JavaScriptEngineImplDuktape.cpp.o
/Users/mac/Documents/WorkSpace/JavaScriptEngine/JavaScriptEngineImpl/src/JavaScriptEngineImplDuktape.cpp:130:13: error: '~DuktapeStackVerification' has
      a non-throwing exception specification but can still throw [-Werror,-Wexceptions]
            throw utils::Exception(errorMsg);
            ^
/Users/mac/Documents/WorkSpace/JavaScriptEngine/JavaScriptEngineImpl/src/JavaScriptEngineImplDuktape.cpp:123:6: note: destructor has a implicit
      non-throwing exception specification
     ~DuktapeStackVerification() {
     ^
1 error generated.
make[2]: *** [JavaScriptEngineImpl/src/CMakeFiles/JavaScriptEngine.dir/JavaScriptEngineImplDuktape.cpp.o] Error 1
make[1]: *** [JavaScriptEngineImpl/src/CMakeFiles/JavaScriptEngine.dir/all] Error 2
make: *** [all] Error 2

Here is what/how I build:

a483e709e1e8:buildDirJavaScriptEngine mac$ cmake ../JavaScriptEngine/ -DWITH_DUKTAPE=ON -DWITH_V8=ON
Creating the build directory for the JavaScriptEngineLibrary with build type: DEBUG
CMAKE_INSTALL_PREFIXis=====/Users/mac/Documents/WorkSpace/buildDirJavaScriptEngine/../Artifacts
====> Exporting Target Tuple using /Users/mac/Documents/WorkSpace/JavaScriptEngine/../BuildCommons/cmake/config.guess
====> Target Tuple is x86_64-apple-darwin18.7.0
Dependencies SHARED +++++ /Users/mac/Documents/WorkSpace/Artifacts/lib/libLogger.dylib;-Wl,-rpath,/Users/mac/Documents/WorkSpace/buildDirJavaScriptEngine/../Artifacts/lib
Dependencies SHARED +++++ /Users/mac/Documents/WorkSpace/Artifacts/lib/libException.dylib;-Wl,-rpath,/Users/mac/Documents/WorkSpace/buildDirJavaScriptEngine/../Artifacts/lib
Dependencies SHARED +++++ /Users/mac/Documents/WorkSpace/Artifacts/lib/libJsonContainer.dylib;-Wl,-rpath,/Users/mac/Documents/WorkSpace/buildDirJavaScriptEngine/../Artifacts/lib
Dependencies +++++ /Users/mac/Documents/WorkSpace/buildDirJavaScriptEngine/../Artifacts/include;/Users/mac/Documents/WorkSpace/buildDirJavaScriptEngine/../Artifacts/include/v8
Dependencies SHARED +++++ /Users/mac/Documents/WorkSpace/Artifacts/lib/libDuktape.dylib;-Wl,-rpath,/Users/mac/Documents/WorkSpace/buildDirJavaScriptEngine/../Artifacts/lib
Dependencies STATIC +++++ /Users/mac/Documents/WorkSpace/Artifacts/lib/libv8_monolith.a
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/mac/Documents/WorkSpace/buildDirJavaScriptEngine

This piece of source code is complaining:

~DuktapeStackVerification() {
    m_endStackIndex = duk_get_top_index(m_ctx);
    if (m_beginStackIndex != m_endStackIndex) {
        std::string errorMsg = "beginStackIndex: " + std::to_string(m_beginStackIndex) +
                               " endStackIndex: " + std::to_string(m_endStackIndex) +
                               " func: " + m_func;
        LOG_ERROR(errorMsg, JAVASCRIPTENGINE_IMPL_DUKTAPE_MODULE_NAME);
        throw utils::Exception(errorMsg);
    }
}

score 1 · Answer 1 · answered Aug 28 '19 at 08:48

The compiler is actually telling you what's going on:

error: '~DuktapeStackVerification' has a non-throwing exception specification but can still throw

note: destructor has a implicit non-throwing exception specification

For additional background, you can search for terms like "C++ throw destructor", and you will find (e.g. here or here) that as of C++11, destructors are implicitly marked nothrow(true), because throwing from destructors is generally considered dangerous. To override that default, you'll have to explicitly annotate the destructor as noexcept(false) -- or simply stop throwing there, and use some other mechanism to signal the problem. It looks like an assertion against programming errors anyway, so terminating immediately is probably just as good as throwing an exception.

Questions regarding Javascript Engine error

1 Answers1