[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

Zachary Turner via lldb-commits lldb-commits at lists.llvm.org
Sat Sep 9 13:31:59 PDT 2017

On Sat, Sep 9, 2017 at 12:04 PM Jim Ingham <jingham at apple.com> wrote:

> 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.
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.

if you have

void *foo(int x) {
  // do some stuff

  assert(x < 0 || foo != nullptr);

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:

void *bar(unsigned x) {
  void *ptr = foo(x);
  if (!ptr) {
    // log an error
    return nullptr;
  return ptr;

You just have

void *bar(unsigned x) {
  void *ptr = foo(x);
  return x;

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170909/f9ddd8b5/attachment.html>

More information about the lldb-commits mailing list