Yarp 3.11 Feature preview: Introducing yarp::dev::ReturnValue type #3168
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"); |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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 asfalse
this means that:Logical AND operation between different error type will result in an
return_value_error_generic
error type, i.e.MIGRATION GUIDE
IMPLICATIONS ON THE APPLICATIONS CODE
Since
yarp::dev::ReturnValue
is 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_ok
if the method was successfulreturn_value_error_method_failed
if the method failed, because the given parameters are invalid and the output cannot be computedreturn_value_error_deprecated
orreturn_value_error_not_implemented
if the method is not availablereturn_value_error_not_ready
if 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::ReturnValue
type to propagate the return value from the device to the client.Beta Was this translation helpful? Give feedback.
All reactions