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_status
field is used for the conversion. This field is typically set to a value of thestick10::command_status
enum. ButLongOperationInProgressException
, which is a subclass ofCommandFailedException
, usesstick10::device_status::busy
(= 1) instead. This overlaps with thewrong_CRC
variant of thecommand_status
enum, making it impossible to distinguish the two errors as a user of the C API.Possible solutions:
stick10::command_status
enum and use it forLongOperationInProgressException
.LongOperationInProgressException
to theget_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.)LongOperationInProgressException
inherit fromDeviceCommunicationException
instead ofCommandFailedException
and define a new ID.