Open Xottab-DUTY opened 6 years ago
I must confess I don't know the implications, since I generally only use the exception path. That being said, my understanding was that the handler needs to do some stack unwinding / longjump equivalent to the exception mechanism, since the normal flow of execution is disrupted by a failed operation. In this case, the assertion is only hit if the error handler fails to do that. Am I on the completely wrong track?
Yes, we can make error handler to return boolean value, and if it's false (or callback wasn't even set), then calls to std::terminate.
Implications:
I just need to mimic old luabind (version ~beta7-devel.rc4) behaviour. When the script error occurs old luabind just hangs the script execution and you can continue to play the game. Engine's debug manager will show in the log that's something went wrong, but game won't be crashed, because script errors are not critical. Current version of luabind just calls to std::terminate which makes script errors critical.
Okay, I think I will replace cast_failed_callback and error_callback with std::function<bool( ... )> counterparts and disable terminate on true return value (ie. it has "disable terminate" semantics). Would that be OK?
Sure
Currently when luabind exceptions are disabled, program terminates always on lua errors. Maybe we can allow user to tell luabind crash only when error callback wan't set?
For now, I have modified the code for me: https://github.com/Xottab-DUTY/luabind-deboostified/commit/ee8a074be60ab849b2f4c7bba79b8c6001bf74c3 But this changes original behavior. We need a ~save~ safe method to change that behaviour.