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
There are several noexcept contexts where exceptions are prohibited. For example: on_enter/on_exit handlers for states, not_empty_notificator for mchains. But actions that can throw are often used in such contexts, for example:
A call to so_5::send may throw. If such an exception won't be intercepted, the whole application will crash (due to std::terminate call).
For some types of applications it's a normal behavior. But not always. For example, it's not good to crash a complex GUI application if one so_5::send fails. But it's also not good to just ignore such a problem by using something like that:
Is it always possible to call so_environment_t::stop()? Especially when it's called from state's on_enter/on_exit handlers.
The source code of SObjectizer has to be examined.
It's better to have some helper function that takes a lambda than can throw and wraps it into a noexcept function object that catches exceptions and calls so_environment_t::stop(). Something like:
It will be good to store and then access somehow the reason for the environment's shutdown.
Unfortunately, I have no idea what it can look like. But, obviously, such a feature has to be noexcept (so we can't store std::string or another type that can allocate, maybe an object with std::array<char, N> inside, where N will be reasonably long).
The text was updated successfully, but these errors were encountered:
eao197
changed the title
[ideas] An emergency stop of SOEnv on an exception in noexcept context
[idea] An emergency stop of SOEnv on an exception in noexcept context
Jul 25, 2023
There are several noexcept contexts where exceptions are prohibited. For example: on_enter/on_exit handlers for states, not_empty_notificator for mchains. But actions that can throw are often used in such contexts, for example:
A call to
so_5::send
may throw. If such an exception won't be intercepted, the whole application will crash (due tostd::terminate
call).For some types of applications it's a normal behavior. But not always. For example, it's not good to crash a complex GUI application if one
so_5::send
fails. But it's also not good to just ignore such a problem by using something like that:Maybe the better way is to stop the SObjectizer Environment. Something like:
But there are some open questions:
Is it always possible to call
so_environment_t::stop()
? Especially when it's called from state's on_enter/on_exit handlers.The source code of SObjectizer has to be examined.
It's better to have some helper function that takes a lambda than can throw and wraps it into a noexcept function object that catches exceptions and calls
so_environment_t::stop()
. Something like:Or something like (an additional form of on_enter/on_exit method):
It will be good to store and then access somehow the reason for the environment's shutdown.
Unfortunately, I have no idea what it can look like. But, obviously, such a feature has to be noexcept (so we can't store std::string or another type that can allocate, maybe an object with
std::array<char, N>
inside, where N will be reasonably long).The text was updated successfully, but these errors were encountered: