Casting sol::protected_function_result to sol::error fails

[Rochet2]

#define SOL_CHECK_ARGUMENTS true
#include "sol.hpp"
#include <utility>
#include <cstdio>
#include <functional>

void Error(sol::error const & err)
{
    printf("%s\n", err.what());
}

template<typename T>
bool HandleError(T&& obj)
{
    if (!obj.valid())
    {
        Error(std::forward<T>(obj)); // <----- Here
        return true;
    }
    return false;
}

template<typename ...ARGS>
void PCall(sol::protected_function const & function, ARGS&&...args)
{
    HandleError(function(std::forward<ARGS>(args)...));
}

int main()
{
    sol::state state;
    state["f"] = [&](sol::table t) {
        int x = t["x"];
    };

    int x = 100;
    sol::table t = state.create_table();
    t["x"] = std::ref(x);
    PCall(state["f"], t);
}

I understand that int x = t["x"]; raises an error (at least when SOL_CHECK_ARGUMENTS is defined).
However, for some reason the casting of sol::protected_function_result to sol::error fails in the marked spot with following:
[sol2] An error occurred and panic has been invoked: stack index 1, expected string, received table

Any idea why this happens?
Isnt this the correct way to check the result of the call and get the error message?

Details: VisualStudio 2017 15.8.1, C++14, #define SOL_CHECK_ARGUMENTS true
Sol2: https://github.com/ThePhD/sol2/blob/f438284a47294dc0fc92fd1a8a8959e7cd84809d/single/sol/sol.hpp

[ThePhD]

Just gonna throw this out here: not a clue. It says there's a table on top of the stack. Not sure how a table ended up sitting on top of the stack...

We are calling luaL_error properly and it is passing the proper message through, but for some reason it's not staying on top of the stack which is concerning.

[Rochet2]

Additionally to make things weird Visual Studio has a bug or a "feature" where running in Debug mode will ignore exceptions that are not catched and just continue executing the code on next line.
In Release compilation unhandled exceptions abort as I expect.

So debug causes behavior like this:

Debugging doesnt feel that reliable all of a sudden...

[Rochet2]

When we push stuff to the stack push_popper can be used, error occurs, we push error message, we throw.
Throwing will destruct all objects, so then the popping starts to happen for push_popper and the error message is popped along with the other values we pushed.

Or that is how it looks to me.

[ThePhD]

Oooh, I wasn't even considering the destructors.... thanks! I'll try to debug those specifically.

[ThePhD]

I have decided that this is a sufficiently weird case that I can't actually fix it.

The primary problem is that the only true fix I have basically means I need to mess with performance and add tons of checks for various ill-formed states of the program. It also means I have to commit to making sure that every time you blow up the (actual, real, C) call stack with a call to luaL_error (which may perform a longjmp or throw depending on how you build Lua), I would still guarantee you can get errors out...

I would much rather that you are careful with your accesses and use the proxy methods on the lua["x"]; type or do sol::optional<int> x = lua["x"];. It sucks to have to explicitly annotate things but I don't have a better control mechanism for when things go to hell.