Closed yaoyuan1216 closed 2 years ago
CTI_DETAIL_TRAP
is platform implemented and will lead to this behaviour dependent on your platform:
/// Causes the application to exit abnormally
#if defined(_MSC_VER)
// NOLINTNEXTLINE(cppcoreguidelines-macro-usage)
#define CTI_DETAIL_TRAP() __debugbreak()
#elif defined(__GNUC__)
// NOLINTNEXTLINE(cppcoreguidelines-macro-usage)
#define CTI_DETAIL_TRAP() __builtin_trap()
#elif defined(__has_builtin) && __has_builtin(__builtin_trap)
// NOLINTNEXTLINE(cppcoreguidelines-macro-usage)
#define CTI_DETAIL_TRAP() __builtin_trap()
#else
// NOLINTNEXTLINE(cppcoreguidelines-macro-usage)
#define CTI_DETAIL_TRAP() *(volatile int*)0x11 = 0
#endif
The implementation of this macro aligns with the way how LLVM is handling traps.
The greater issue here is that the unhandled exception handler is called although you provided a handler in fail, however I was not reproduce this since your code runs fine for me:
TEST(regression_tests, fail_handler_called) {
make_exceptional_continuable<int>(supply_test_exception()).fail([]() {
return 1;
});
}
Additionally this usage scenario has a test case already:
TYPED_TEST(single_dimension_tests, are_exceptions_partial_applyable) {
in continuable/test/unit-test/multi/test-continuable-base-errors.cpp
Maybe you left code from debugging that leads to this behaviour?
@Naios yeah, you are right. I neglected one line code.
auto continuable = make_exceptional_continuable<void>(supply_test_exception());
So sorry!
@Naios
When I debug issue #46, I found another bug. It can be reproduced by the following code. I'd like to fix the bug, but have not caught the whole picture yet.
Expected Behavior
Finish normally.
Actual Behavior
Crashed at
CTI_DETAIL_TRAP();
in macroCONTINUABLE_HAS_EXCEPTIONS
.Steps to Reproduce
Your Environment