Yarp 3.11 Feature preview: Introducing yarp::dev::ReturnValue type #3168
randaz81
started this conversation in
Architecture
Replies: 2 comments 2 replies
|
I wonder if the names could be shortened a bit. Instead of:
...have something like:
Or keep case code::error_nws_nwc_communication_error:
return std::string("error_nws_nwc_communication_error");Or: case code::error_nws_nwc_communication_error:
return std::string("command answer lost during network transmission; status unknown"); |
1 reply
|
It would be nice to be able to do something like this: auto ret = iface->doSomething();
switch (ret)
{
case yarp::dev::ReturnValue::return_code::return_value_error_nws_nwc_communication_error: // lengthy, see my above comment
// do something
}I have tried to add another conversion operator: operator return_code() const
{
return value_b;
};And then I can do this: switch (static_cast<yarp::dev::ReturnValue::return_code>(ret))
{
case yarp::dev::ReturnValue::return_code::return_value_error_nws_nwc_communication_error:
// do something
}I am not sure about the pitfalls of this, and yet a static_cast seems to be necessary. Is there any way to achieve the result of the first snippet? |
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Starting from yarp 3.11, we are going to gradually migrate all return values from yarp dev interfaces to the new type yarp::dev::ReturnValue which allows a better understanding of the system behavior (e. g. what happened during an RPC call)
For example, a method like this:
become:
The new type yarp::dev::ReturnValue can assume one of these values:
yarp::dev::ReturnValue is automatically convertible to bool. All values different from
return_value_ok(which is obviouslytrue) are considered asfalsethis means that:Logical AND operation between different error type will result in an
return_value_error_genericerror type, i.e.MIGRATION GUIDE
IMPLICATIONS ON THE APPLICATIONS CODE
Since
yarp::dev::ReturnValueis automatically casted to bool, all user applications will continue to work, without any change to the code. i.e.However, in the future, users might want to migrate to a more fine-grained handling of error codes:
IMPLICATIONS ON THE DEVICES CODE
If a device inherits from a interface whose methods use the yarp::dev::ReturnValue, some modification is required to compile successfully.
The required modifications are very easily since just the return values of the methods need to be modified.
return_value_okif the method was successfulreturn_value_error_method_failedif the method failed, because the given parameters are invalid and the output cannot be computedreturn_value_error_deprecatedorreturn_value_error_not_implementedif the method is not availablereturn_value_error_not_readyif the device is not correctly initialized because one parameter is missing, a pointer is invalid or it requires to be activated before processing meaningful dataIMPLICATIONS ON THE NWS/NWC CODE
The modification on these devices, is slightly more difficult, since some logic might apply. Wrappers are REQUIRED to propagate the error code from the attached device.
For n NWS device:
For a NWC device:
Please note that the required modifications might be slightly different if the NWC/NWS employs a THRIFT-based communication and that also the protocol (i.e. the .thrift file) needs to employ the
yarp::dev::ReturnValuetype to propagate the return value from the device to the client.All reactions