> On Sep 19, 2016, at 2:31 PM, Zachary Turner via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > > > On Mon, Sep 19, 2016 at 2:20 PM Mehdi Amini <mehdi.am...@apple.com > <mailto:mehdi.am...@apple.com>> wrote: > > > I’m surprise by your aversion to assertions, what is your suggested > alternative? Are you expecting to check and handle every possible invariants > everywhere and recover (or signal an error) properly? That does not seem > practical, and it seems to me that it'd lead to just involving UB (or > breaking design invariant) without actually noticing it. > > > Also many asserts are in header files so even if you build llvm and clang > > with asserts off, but then build our project that uses LLVM with asserts > > on, you get LLVM and clang asserts when you don't want them. > > It is not really supported to use the LLVM C++ headers without assertions and > link to a LLVM build with assertions (and vice-versa). > > It seems to me that you are mixing two things: asserting on user inputs vs > asserting on internal invariants of the system. LLVM is very intensive about > asserting on the second category and this seems fine to me. > Asserting on external inputs is not great (in LLVM as much as in LLDB). > > The asserting error class above falls into the second category and is a great > tool to enforce programmer error > > > I can kind of see both sides on this one. Yes, if you can catch instances of > UB before it happens that's helpful. At the same time, when you've got a > product (such as, say, Xcode), you also want to try as hard as possible not > to bring the whole product down. In lldb we have lldbassert, which asserts > for real in debug, but in release it logs an error to a file. This is nice > because if someone submits a crash report, we can see the assertion failure > in the log file. > > Now, obviously the *real* solution is to make LLDB out-of-process so it > doesn't bring down Xcode when it crashes. But (and I have no knowledge of > the Xcode / LLDB integration) I can easily see this being a monumental amount > of effort. >
Even then, IMO you are not out of the business of not crashing on people Sure, now you didn't crash all of Xcode, but you still lost somebody's debug session with potentially valuable state in it... It sounds like llvm::Expected + lldbassert() is a good combination; it makes sure we don't just drop error conditions on the ground, but it also makes sure that we don't just give up the ghost and crash.. > Personally, asserting in LLDB doesn't affect me and I'm fine with lldb::Error > asserting.. But I can kind of see the argument for not wanting it to assert. > > > On the other hand, if we had better test coverage, then all I wonder if catching them all can't somehow be reduced to the halting problem :) Most would already be great! > of these assertions would be caught during test anyway. Which brings us back > to item #2 on my list... > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev Thanks, - Enrico 📩 egranata@.com ☎️ 27683
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
