Error handling and use of assertions in LLDB
+
+
+ + Contrary to clang, which is typically a short-lived process, LLDB debuggers + stay up and running for a long time, often serving multiple debug sessions + initiated by an IDE. For this reason LLDB code needs to be extra thoughtful + about how to handle errors. Below are a couple rule of thumbs: +
-
+
- Fatal errors. + Aborting LLDB's process using llvm::report_fatal_error() or abort + should be avoided at all costs. It's acceptable to use + llvm_unreachable() + for actually unreachable code such as the default in an otherwise exhaustive switch statement. + +
- Assertions. + Assertions (from assert.h) should be used liberally to assert internal consistency. + Assertions shall never be used to detect invalid user input, such as malformed DWARF. + An assertion should be placed to assert invariants that the developer is convinced will + always hold, regardless what an end-user does with LLDB. + +
- Invalid input. + To deal with invalid input, such as malformed DWARF, missing object files, or otherwise + inconsistent debug info, LLVM's error handling types such as + llvm::Expected<T> + should be used. Functions that may fail should return an + llvm::Optional<T> + result. + +
- Soft assertions. + LLDB provides lldb_assert() as a soft alternative to cover the middle ground + of situations that really indicate a bug in LLDB, but could conceivably happen. + In a Debug configuration lldb_assert() behaves like + assert(). In a Release configuration it will print a warning and encourage the + user to file a bug report, similar to LLVM's crash handler, and then return + execution. Use these sparingly and only if error handling is not otherwise feasible. + +