3 ms·

> Can assertions be used in production? Yes > What should I be asserting on? Invariants > Can I customize how assert behaves? It should abort the program,

by eps 2mo ago

> Can assertions be used in production? Yes > What should I be asserting on? Invariants > Can I customize how assert behaves? It should abort the program, logging the stack and whatever the context you pass into in, printf-style. If it doesn't abort, it just buries the issue of the program being in incorrect internal state. It should never be OK.

benj111 2mo ago
I think part of the problem is that assert is used for different things. You can use assert to cover a case that should never happen, you can also use assert to catch programming errors during development. It's arguable that you don't want the second group in a production build. That should have been caught in testing. But then there's the use where it's a lazy person's if statement. Instead of dealing with the issue assert it. I'm undecided whether this is a net good. Would the test have been implemented anyway?
tom_ 2mo ago
Additionally recommended: if attached to a debugger, the program should stop in the debugger, immediately, without printing a message (you can look at the code), or getting a stack trace (the debugger can do that), or whatever else, to avoid possibly triggering further asserts or causing more problems. This leaves the state just as it was (or as near as feasible), so that it can be investigated. After being stopped in this way, it must be possible to resume execution somehow. Asserts are code too, and they can be wrong, and it may not be clear why, or what the ramifications might actually be for the specific case - continuing to let the code run can be useful for debugging purposes.
- rramadass 2mo ago
  The ASSERT (note caps) macro in Microsoft MFC library does this. It uses a "INT 3" instruction (x86/x64) via "AfxDebugBreak" to invoke the debugger. Since the above is a well-known technique, it has now been generalized and standardized via "std::breakpoint" in C++26 - https://en.cppreference.com/cpp/utility/breakpoint https://en.cppreference.com/cpp/utility/breakpoint This function standardizes many similar existing facilities: __builtin_debugtrap from LLVM, DebugBreak() from Win32 API, __debugbreak Microsoft Specific C/C++ extension, debugger_break from boost.test, assert(false), _asm { int 3 } (MSVC) and asm("int3") (GCC/clang) for x86 targets, etc.

by eps 2mo ago

benj111 2mo ago

I think part of the problem is that assert is used for different things. You can use assert to cover a case that should never happen, you can also use assert to catch programming errors during development. It's arguable that you don't want the second group in a production build. That should have been caught in testing. But then there's the use where it's a lazy person's if statement. Instead of dealing with the issue assert it. I'm undecided whether this is a net good. Would the test have been implemented anyway?

tom_ 2mo ago

Additionally recommended: if attached to a debugger, the program should stop in the debugger, immediately, without printing a message (you can look at the code), or getting a stack trace (the debugger can do that), or whatever else, to avoid possibly triggering further asserts or causing more problems. This leaves the state just as it was (or as near as feasible), so that it can be investigated. After being stopped in this way, it must be possible to resume execution somehow. Asserts are code too, and they can be wrong, and it may not be clear why, or what the ramifications might actually be for the specific case - continuing to let the code run can be useful for debugging purposes.

rramadass 2mo ago
The ASSERT (note caps) macro in Microsoft MFC library does this. It uses a "INT 3" instruction (x86/x64) via "AfxDebugBreak" to invoke the debugger. Since the above is a well-known technique, it has now been generalized and standardized via "std::breakpoint" in C++26 - https://en.cppreference.com/cpp/utility/breakpoint https://en.cppreference.com/cpp/utility/breakpoint This function standardizes many similar existing facilities: __builtin_debugtrap from LLVM, DebugBreak() from Win32 API, __debugbreak Microsoft Specific C/C++ extension, debugger_break from boost.test, assert(false), _asm { int 3 } (MSVC) and asm("int3") (GCC/clang) for x86 targets, etc.