The C API translates the C++ exceptions to integer values (see NK_C_API.cc:get_with_status). For instances of CommandFailedException, the last_command_status field is used for the conversion. This field is typically set to a value of the stick10::command_status enum. But LongOperationInProgressException, which is a subclass of CommandFailedException, uses stick10::device_status::busy (= 1) instead. This overlaps with the wrong_CRC variant of the command_status enum, making it impossible to distinguish the two errors as a user of the C API.
Possible solutions:
- Add a new value to the
stick10::command_status enum and use it for LongOperationInProgressException.
- Add a special case for the
LongOperationInProgressException to the get_with_status function and return a unique ID for it. (I don’t really like this option because it makes the error handling code more complicated.)
- Let
LongOperationInProgressException inherit from DeviceCommunicationException instead of CommandFailedException and define a new ID.
The C API translates the C++ exceptions to integer values (see
NK_C_API.cc:get_with_status). For instances ofCommandFailedException, thelast_command_statusfield is used for the conversion. This field is typically set to a value of thestick10::command_statusenum. ButLongOperationInProgressException, which is a subclass ofCommandFailedException, usesstick10::device_status::busy(= 1) instead. This overlaps with thewrong_CRCvariant of thecommand_statusenum, making it impossible to distinguish the two errors as a user of the C API.Possible solutions:
stick10::command_statusenum and use it forLongOperationInProgressException.LongOperationInProgressExceptionto theget_with_statusfunction and return a unique ID for it. (I don’t really like this option because it makes the error handling code more complicated.)LongOperationInProgressExceptioninherit fromDeviceCommunicationExceptioninstead ofCommandFailedExceptionand define a new ID.