[lldb-dev] LLDB Evolution - Final Form

[Nico Weber via lldb-dev]

On Tue, Sep 20, 2016 at 4:37 PM, Ted Woodward via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

>
> From: lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org] On Behalf Of
> Zachary Turner via lldb-dev
> Sent: Tuesday, September 20, 2016 12:47 PM
>
> > This kind of philisophical debate is probably worthy of a separate
> thread :)  That being said, I think asserts are typically used in places
> where the assert firing means "You're going to crash *anyway*"
>
> This is emphatically NOT the case.
>
> One of the first tasks I was given when I started at Qualcomm was to fix
> the disassembler for Hexagon. It was a mess - it would assert if the
> disassembly tables couldn't identify an opcode. Maybe that's fine for an
> assembler, assert if you can't generate an opcode, but an unidentified
> opcode should print a warning and move on. It's not a fatal error to
> disassemble data!
>
> There are other instances of this in llvm. I agree with Greg - libraries
> shouldn't assert.  Send an error back to the caller, and let the caller
> handle it. A typo in my expression that lldb sends to clang shouldn't crash
> my debug session.
>

It depends on what you use the assert for, right? If it's used to document
invariants that you control, then having them crash is ok, since those
should always be true. You shouldn't assert on input you don't control.

So in a public api, you'd do:

my_err my_public_api(int p) {
  if (p < 0 || p > 10) {
    return make_err("p must be between 0 and 10");
  internal_fun(p);
}

But then in internal_fun you can do

void internal_fun(int p) {
  assert((p >= 0 && p <= 10) && "must pass correct p");
}


>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160920/806b2dd8/attachment.html>