<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I think we are talking at cross purposes. Seems to me you are saying “If we can assert that the answers to questions I ask must always copacetic, then we can express that in software, and that will make things so much easier". I’m saying "my experience of the data debuggers have to deal with is such that assuming such assertions will lead you to over-react to such errors. Instead you should write your code so that if somebody gives you bad data you don’t fall over allowing the people who called you to decide how important the error was.” Every core file that was written out by OS X for years had a section that was ill-formed. Asserting when you get an ill-formed object file might seem a good way to ensure that you don’t have to make guesses that might lead you astray. But the people who need to load core files on OS X are rightly unmoved by such arguments if lldb disappears out from under them when reading in core files.<div class=""> </div><div class=""><div class="">Jim<br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 9, 2017, at 1:31 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sat, Sep 9, 2017 at 12:04 PM Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">I disagree here. If you can reasonably unwind from an error you should do so even if you can’t figure out how you could have gotten an answer you didn’t expect. If an API is returning a pointer to something you should assume it might return nullptr unless the API explicitly states otherwise. </div></div></blockquote><div class="">But that's exactly what an assert is. It's an explicit statement by the API about what should happen. Which is why by adding them liberally, these assumptions can then be propagated all the way up through many layers of the code, vastly simplifying the codebase.</div><div class=""><br class=""></div><div class="">if you have</div><div class=""><br class=""></div><div class="">void *foo(int x) {</div><div class=""> // do some stuff</div><div class=""><br class=""></div><div class=""> assert(x < 0 || foo != nullptr);</div><div class="">}</div><div class=""><br class=""></div><div class="">Then you're documenting that if x is greater than 0, the caller doesn't need to check the return value for nullptr. Now instead of this:</div><div class=""><br class=""></div><div class="">void *bar(unsigned x) {</div><div class=""> void *ptr = foo(x);</div><div class=""> if (!ptr) {</div><div class=""> // log an error</div><div class=""> return nullptr;</div><div class=""> }</div><div class=""> return ptr;</div><div class="">}</div><div class=""><br class=""></div><div class="">You just have</div><div class=""><br class=""></div><div class="">void *bar(unsigned x) {</div><div class=""> void *ptr = foo(x);</div><div class=""> assert(x);</div><div class=""> return x;</div><div class="">}</div><div class=""><br class=""></div><div class="">And now the caller of bar doesn't have to check either. The code has greatly reduced complexity due to the butterfly efflect of propagating these assumptions up.</div><div class=""><br class=""></div><div class="">This is a simple example but the point is that building assumptions into your API is a good thing, because you can enforce them and it vastly simplifies the code.</div></div></div>
</div></blockquote></div><br class=""></div></div></div></body></html>