Sebastien Roy wrote: > On Thu, 2008-08-14 at 17:09 +0100, John Levon wrote: > >> On Thu, Aug 14, 2008 at 09:01:41AM -0700, Danek Duvall wrote: >> >> >>> On Thu, Aug 14, 2008 at 03:12:20PM +0800, Max Zhen wrote: >>> >>> >>>> 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. >>>> >>> Wouldn't a specialized exception be more appropriate? That would allow >>> people to be more specific in their error handling, and not have to wrap >>> calls to the dlpi methods as tightly as a generic exception would force >>> them to. You could even inherit DLPIError (or whatever) from OSError, if >>> you like. >>> >> I don't get the benefit. We're returning OS errors (errno), and we have no >> additional information beyond errno/strerror. >> > > But this isn't true. libdlpi has an entire error space separate from > errno... There are dozens of error codes unrelated to errno, and it is > defined as the union of DL_* errors in <sys/dlpi.h> and DLPI_* errors in > <libdlpi.h>. ?Only if the error returned from a libdlpi function is > DL_SYSERR is errno set to something meaningful. > OK. I can see that it makes sense to add a new exception for libdlpi specific error. So, two exceptions can be raised from this dlpi module: + OSError - for errors set in errno + dlpi.error - for dlpi specific error other than DL_SYSERR
Max > -Seb > > >
