DavidSpickett wrote: I thought about it, and realised that the meaning of IsValid is unique for SBError compared to other objects.
Other objects: * IsValid() == true means it has an underlying object and so it's safe to call methods on the other SB object * IsValid() == false means there's no underlying object, don't call anything else on the SB object This matches my, and most people's I think, intuition for what IsValid would mean. However, for SBError: * IsValid() == true almost always implies that Fail() is also true. As we wouldn't otherwise put a valid object in there. * IsValid() == false implies that Success() is also true. If it were false, we would have put some object in there and made the SBError valid in doing so. Evidence to support this is that many methods on SBError have fallbacks for invalid error objects. They won't cause crashes like it would for other SB objects. Success() defaults to true, which means you would have no reason to inspect the error anymore, and Fail defaults to false, for the same reason. So I think I should revert this and instead document SBError::IsValid's different behaviour. What do you think? https://github.com/llvm/llvm-project/pull/170156 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
