adapt to the NULL removal from rmw result validation string

[gaoethan]

Change to align to the update of APIs rmw_*_validation_result_string()
Signed-off-by: Ethan Gao ethan.gao@linux.intel.com

Connects to ros2/rmw#130

[gaoethan]

This PR relates to PR: #ros2/rmw#130

[mikaelarguedas]

All these functions should not raise as their goal is to return the error message. That's why they were raising only on NULL return (unknown error message).

So if we decide to not return NULL on "unknown error" we should just delete these if blocks completely.

If we go back to return NULL on unknown error code, we should not change this file at all.

[gaoethan]

yes, I initially intend to show the specific validation message, but the error msg is returned from the final result_list, there is no need now, thanks for your comments.

[mikaelarguedas]

It may be worth keeping this check as it will allow us to keep a good fallback behavior:

• If the X_NAME_IS_VALID we return None without raising
• If the validation error string is not NULL we return it
• If it's NULL: Something is wrong (that should never happen) so we raise and return NULL as C/Python extensions must do when they raise.

Sorry for the back and forth on this but I believe that this PR is not necessary.

Edit: Actually it doesn't make sense to test for something that by design will never happen so let's not check it in any of the client libraries 👍 let's keep this PR as is

[mikaelarguedas]

thanks @gaoethan for iterating