The intention in the scope of this change is just to check that the new overload is exposed correctly through the Python API.
In general, guaranteeing specific error codes (messages?) is likely impractical: 1. It's not always easy to do the proper checks (ex. for 'file-not-found' you'd actually get a null process, nothing more - see SBTarget::LoadCore()). 2. It's unlikely that many clients need or want to check for specific errors. 3. Such a strict contract would be very fragile (ex. adding more specific error condition detection would likely break the contract) Perhaps ironically, I could take advantage of very specific error codes for my scenario, but I don't think it's feasible. So for LoadCore() I'd like to aim for more of a middle ground: accurate success/fail status + an informative error content that can be used for diagnostics (logging) and maybe as a weak hint. What do you think? On Wed, Jun 13, 2018 at 9:59 AM, Adrian McCarthy via Phabricator < revi...@reviews.llvm.org> wrote: > amccarth added inline comments. > > > ================ > Comment at: lldb/trunk/packages/Python/lldbsuite/test/ > functionalities/postmortem/minidump-new/TestMiniDumpNew.py:78 > + self.assertFalse(self.process, PROCESS_IS_VALID) > + self.assertTrue(error.Fail()) > + > ---------------- > Is it worth checking something more specific here? That the error > indicates the file was not found? > > > Repository: > rL LLVM > > https://reviews.llvm.org/D48049 > > > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits