Note that if something originates from user input, then i agree there's no excuse for a fail fast. But after all the inputs have been sanitized, I think it's fine to fast fail On Fri, Sep 8, 2017 at 7:12 PM Zachary Turner <ztur...@google.com> wrote:
> On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator < > revi...@reviews.llvm.org> wrote: > >> >> I know there is debate about this one side and another but for lldb this >> is a settled issue. Unless you really are in a state where the world is >> about to come crashing down around you, you can't raise a fatal error in >> lldb. And in this case, the world is only very minorly strange, so it is >> certainly not appropriate. > > > I don't agree that this is a settled issue in LLDB. > > For starters, clang already does this, and LLDB links against libclang. > > Second, a year or so ago, i recall Greg saying that LLDB now runs out of > process in Xcode, which should make this a non issue. > > Finally, by allowing inconsistent state to propagate through the code you > are only hurting yourself, as you're ultimately not preventing any > crashes. It'll just crash later when you de reference a null pointer or > read some corrupt memory. Furthermore, it actually increases the > likelihood of introducing bugs, due to the added complexity and technical > debt introduced by untested code paths > >>
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
