proposals for enumeration of interface-specific error codes
Jason Kraftcheck
kraftche at cae.wisc.edu
Tue Aug 24 13:11:41 CDT 2010
On 08/24/2010 11:58 AM, Miller, Mark C. wrote:
> Hi Jason,
>
> I may be missing something but let me ask why not just allow following.
>
> If iBase_ErrorType looked like...
>
> iBase_ErrorType {
> iBase_SUCCESS, // do we need iRel_SUCCESS, iMesh_SUCCESS?
Absolutely not. The entire point of having one shared enum was to avoid
duplicating error code values for errors that are common to all interfaces.
> iBase_MESH_ALREADY_LOADED, // shouldn't this be an iMesh_ error code
Probably. Or perhaps it should just be iBase_ALREADY_LOADED.
> .
> .
> .
> iMesh_NOT_LAGRANGE_COORDS,
> iRel_FOO_BAR,
> iBase_YET_ANOTHER_ERROR
> iMesh_NOT_A_PART_HANDLE,
> .
> .
> .
> iBase_MAX_ERROR_CODES // always last
I disagree with this also. If you really want this, it should be
written as iBase_LAST_ERROR_CODE = iBase_FAILURE (or whatever the last
one is.) Otherwise you have an enum value that is always invalid. And
further, if in some implementation you have a function that switches in
an enum type, compilers tend to (correctly) warn that not all enum
values are included in the switch if you don't have a case for this
invalid error code. Effectively, it ends up being an extra, invalid
error code rather than the actual max value.
> }
>
> As new error codes for interfaces are added, I see no reason to
> 'group' them in terms of numbering. That might be cosmetically nice as
> far as the header file looks but I don't see any real reason to do it.
>
The specific requirement was to support implementations that do
getDescription by indexing into an array. As I said before, I don't
think that is the best way to implement getDescription. However, some
want to do that and intermixing the codes will definitely break that.
Further, the cosmetic factors are significant in this case. It would be
unnecessarily difficult and error prone for a user of the interface to
determine what subset of the error codes they expect to need to deal
with if they are an interleaved mess.
- jason
More information about the tstt-interface
mailing list