BTW, not to exclude the positive because it doesn't need discussing: all the rest of the changes you were proposing seem appropriate and good to me. Thanks for taking the trouble to clean this up.
Jim > On Jan 31, 2017, at 5:45 PM, Zachary Turner <ztur...@google.com> wrote: > > Yea, there may be value in both. If i ever tried to do this I'd probably take > the approach of converting all the obvious cases first that should enforce > checking and then see what's left. Then we could use llvm:Error and > lldb::Status, or something > On Tue, Jan 31, 2017 at 5:39 PM Jim Ingham <jing...@apple.com> wrote: > Yeah, I have no idea how you'd make sure that the SBError returned to Python > in a Python SBValue was checked before it went out of scope, and I'm not sure > it's our business to be enforcing that... So we're going to have to do > something special for those errors. We also use the pattern where we return > a count and an error, but ofttimes you don't care why you got nothing, so you > just check the count. The error is informational. Making that obnoxious > would also not be a plus. I actually think there's some value to having > "programming errors that must be checked" and informational errors. Maybe we > need both. > > Jim > > > On Jan 31, 2017, at 5:32 PM, Zachary Turner <ztur...@google.com> wrote: > > > > llvm::Error only enforces checking at the point that it goes out of scope. > > So the example you mention should be supported, as long as you propagate > > the value all the way up and don't destroy it. There's also ways to > > explicitly ignore an Error (similar to casting to void to make the compiler > > not warn about unused variables), so as a last resort we could put code > > like that in the SB implementation if we had to > > On Tue, Jan 31, 2017 at 5:23 PM Jim Ingham <jing...@apple.com> wrote: > > I think we discussed this before, but we need an informational error > > object. IIRC, the llvm::Error has to be checked. But for instance if you > > ask a value object to evaluate itself, but you've moved to a section of > > code where the variable has no location, then evaluating that value will > > result in an error. But that isn't an error the value object code needs to > > do anything about. And it might go all the way up through the SB & Python > > API's before it's appropriate to check the error. > > > > IIRC, the llvm::Error is one of those "you have to check it or you get > > smacked by the compiler" dealies. That's appropriate for some of our uses > > of Error, but not all. > > > > Jim > > > > > > > On Jan 31, 2017, at 4:01 PM, Zachary Turner via Phabricator via > > > lldb-commits <lldb-commits@lists.llvm.org> wrote: > > > > > > zturner added a comment. > > > > > >> Move Error from Core -> Utility > > > > > > Also, I almost forgot. > > > > > > Long term: Delete and use `llvm::Error` > > > > > > > > > https://reviews.llvm.org/D29359 > > > > > > > > > > > > _______________________________________________ > > > lldb-commits mailing list > > > lldb-commits@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
