DavidSpickett wrote: > We're describing it as empty, but the documentation does imply that empty can > equal success. This confuses me a bit because if I pass an SBError to a > function that is expected to return an Status it should populate the > underlying status and thus IsValid() would return true if there is is an > error or a success correct?
This is the assumption I made, but in at least one instance we do not do this, the one I changed. It's not invalid to return a IsValid true success, but evidence points to it not being required. I think you're right that ideally if the API knows something succeeded it should return a valid error object. This fits the mental model of IsValid meaning "can I trust this" (or like our internal enum `eYes eNo eDontknow`). Which I'd like to do I just need to find a reasonably systematic way to find places where we don't do this right now. An alternative @JDevlieghere suggested was to have SBError default construct to something valid. Problem with that is: ``` err = SBError() # I'd expect IsValid to be false here target.Whatever(err) # This may or may not make it valid, intuition says it would make it valid whether success or failure ``` Which I think takes SBError from one special case to another. https://github.com/llvm/llvm-project/pull/170862 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
