Sebastien Roy wrote: > Hi Max, > > I'm fine with your responses, I only have one follow-up question: > > On Thu, 2008-08-14 at 15:12 +0800, Max Zhen wrote: > >> Sebastien Roy wrote: >> >>> In documenting all of the functions, the definition of error semantics >>> isn't brought up at all. For a Committed interface, I would expect that >>> to be made explicit. I've asked some specific questions regarding >>> return values in-line, but this is more of a general comment that I >>> think needs to be addressed. >>> >>> >> In general, error handling in Python code is done by catching the >> exception raised by the function it calls. It is required to do so when >> writing C extension for Python. >> So, in this dlpi module for Python, I followed the requirement by >> calling PyErr_SetString(PyExc_OSError, err_code_from_libdlpi_interface) >> to raise the exception whenever dlpi interface returns an error. >> >> So, in C, we check return value for error, but, in Python, we raise >> exceptions, instead. And PyErr_setString() is the standard way to raise >> an exception in C code for other Python code to catch and handle. >> > > Okay, and you're not introducing new exception types that may need to be > part of the Committed interface (i.e., you're only throwing "standard" > exceptions like RuntimeError)? > No, I did not introduce new exception type. The type I raised is PyExc_OSError, which is a standard exception type defined by Python. And I don't see any point to create a new one here.
Max > Thanks, > -Seb > > >
