Add throwing versions of ROS parameter loading functions

[jdlangs]

This expands the API of rct_ros_tools to include utility loading functions that return the loaded object directly, throwing an exception if a failure occurs. This allows a user to obtain the loaded objects without creating an initial invalid temporary object. The overloads of these functions which return bool are reimplemented to call the throwing version and catch the exception if thrown.

Let me know what you think.

[jdlangs]

@Levi-Armstrong I didn't realize this never got merged. Went ahead and rebased on the most recent master (Isometry3d)

[marip8]

@jdlangs out of curiosity, what is the advantage of throwing an exception vs. the boolean return/output argument approach implemented here? To my knowledge, none of the output arguments are assigned until a temporary object or rvalue of the same type has successfully been created within the scope of the function. Is the risk we are trying to avoid the case where a user ignores the boolean return and uses an incorrect, default-constructed object? Or is there other reasoning behind the change?

[jdlangs]

It's to avoid forcing the user to create an object that exists in an invalid state before something else fixes it. And I consider it cleaner design for functions to output data rather than modify existing data.

[jdlangs]

FYI, this is also encouraged by the current C++ core guidelines: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-out

[marip8]

Makes sense. I haven't decided which I personally prefer, but it's been a topic of discussion recently on a few repositories. Generally the overhead of the extra lines in the try-catch block has been enough to dissuade me from using that method. Maybe this is a better practice, especially if output parameters are being discouraged in the core guidelines

[jdlangs]

The true modern style would be to return an std::variant that contains either the value or the reason it failed. But that's only available in C++17 and I don't think the overhead of using it is any better than exceptions. std::optional is also possible but should be avoided for cases like this because it throws away the failure information.

I personally like exceptions because it completely decouples the program logic from the error-handling logic. I can decide an error like this is unrecoverable and just let the top-level catch get it. But I admit it's mostly a subjective preference.