Renaud Manus wrote: > You cannot just return scf_error() because fmri_to_entity() > is only supposed to return: > SCF_ERROR_NO_MEMORY > ...
Drive-by design comment: Callers should never assume that they know the full list of errors that a function could return. There might be a favored few that are likely and have well-documented meanings, but the caller should always be prepared to handle *any* error return, including error codes that were not defined when the caller was written. Corollary: The specification for a function should not imply that the list of errors shown is the complete list of possible error codes that function might return. Architectural note: Integer error codes are really inflexible, and behave poorly when the system is extended. When an extension creates a new failure mode (for example, when the introduction of NFS introduced network failure modes to file system operations), the implementer has a choice of two poor answers: introduce a new error code (and thus guarantee that existing callers can't do anything useful with it), or use an existing error code (and thus not convey the actual failure). Error reporting schemes should take this into account and allow for a hierarchy of error reports, where an extension might report an existing error but with additional information that allows finer-grained diagnosis. In Java, Exception subclassing helps a lot here. It's harder in C.
