On 1 May 2017 at 19:48, Zachary Turner via lldb-dev <lldb-dev@lists.llvm.org> wrote: > > > On Mon, May 1, 2017 at 11:28 AM Jim Ingham <jing...@apple.com> wrote: >> If it is actually causing confusion (I haven't experienced such yet) I >> don't mind typing some extra letters. > > I think that's in part because llvm::Error isn't very prevalent inside of > LLDB (yet). I actually tried to use llvm:Error a couple of times, but I had given up on it each time because it make all files which do "using namespace llvm && lldb_private;" not compile because of the ambiguity, so I welcome the rename wholeheartedly.
For me the biggest advantage of llvm::Error is the integration with Expected<T>, avoiding the "do I make the Error the return value (and return the *real* result by reference), or the other way around", dilemma. > >> >> >> As we've discussed several times in the past, we often use errors for >> informational purposes (for instance in the ValueObject system) with no >> programmatic requirement they be checked. So the llvm::Error class is not a >> drop-in replacement for our uses of lldb_private::Error in subset of its >> uses. More generally, the environment the debugger lives in is often pretty >> dirty, bad connections to devices, uncertain debug information, arguments >> with clang about what types mean, weird user input, etc. But the job of the >> debugger is to keep going as well/long as it can in the face of this. For >> something like a compiler, if some operation goes bad that whole execution >> is likely rendered moot, and so bagging out early is the right thing to do. >> For lldb, if the debug info for a frame is all horked up, users can still >> resort to memory reading and casts, or some other workaround, provided the >> debugger stays alive. This makes me a little leery of adopting an >> infrastructure whose default action is to abort on mishandling. > > Just re-iterating from previous discussions, but it only does that in debug > mode. When you have a release build, it will happily continue on without > aborting. The point of all this is that you catch unhandled errors > immediately the first time you run the test suite. > > Even if you have a bad connection, uncertain debug information, etc you > still have to propagate that up the callstack some number of levels until > someone knows what to do. All this class does is make sure (when in debug > mode) that you're doing that instead of silently ignoring some condition. > > That said, it certainly seems plausible that we could come up with some kind > of abstraction for informational status messages. With that in mind, I'll > change my original renaming proposal from LLDBError to Status. This way we > will have llvm::Error and lldb_private::Status. I think Status is better than LLDBError, although the fact that we will then have gazillion of declarations "Status error;" almost counterbalances that. _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
