RFC: Error handling in release builds aka "can I use lldbassert or not?"

I have a very strong opinion on this topic. The debugger should never assert when reporting an error is sufficient. The only time the debugger should assert (to a user, crash) is when it’s going to crash anyway, and it’s basically dead in the water.

The example from Phab that @DavidSpickett posted:
default:
lldbassert(“Found type unknown type value %d”, type);
return {};
Should not be an assert. If I load a new image with new DWARF info that lldb doesn’t handle, it shouldn’t crash. It should try to keep going as best it can. Print out an error message. If I’m working on lldb, I can grep for the message, and run lldb in a debugger to see why it hit that spot. If I’m a user, the debugger should NEVER crash.

In the case of the assert in RegisterContextPOSIXCore_arm64.cpp, report an error and fail. I might have another target open in lldb, or another core loaded, and my session just got destroyed.

I’m speaking as an embedded developer who’s customers debug multiple heterogeneous cores, running Android, Linux, QNX and multiple RTOSes. If I’m debugging AArch64 RedHat and multiple Hexagon QuRT instances, and the AArch64 session asserts and takes down my entire debug session, I’m going to be mad.

Just say no to asserts! :smiley:

2 Likes