If I do not care RsslError, especially when there is not much you can do if function likes rsslReleaseBuffer fails (perhaps it never fail if used correctly).
No unfortunately passing nullptr or NULL will result in a fault when an error occurs and the API attempts to assign a value.
With the Elektron-SDK suite of APIs it is highly recommended to test the return values and at least log the result as it significantly aids in diagnosing faults in production environments. For RsslReleseBuffer the API is used to return an object to a memory pool and thus a failure could mean shortly the pool is exhausted and no new data can be processed.
Is RsslError::text always populated in case of error? Obviously RsslError::text is more readable than RsslError::rsslErrorId.
Here's one I made earlier,
if (RSSL_RET_SUCCESS != rsslReleaseBuffer (buf, &rssl_err)) { LOG(WARNING) << "rsslReleaseBuffer: { " "\"rsslErrorId\": " << rssl_err.rsslErrorId << "" ", \"sysError\": " << rssl_err.sysError << "" ", \"text\": \"" << rssl_err.text << "\"" " }";}
Other functions sometimes return codes which need helpers to decode,
if (RSSL_RET_SUCCESS != rsslEncodeMsgComplete (&it, RSSL_TRUE /* commit */)) { LOG(ERROR) << "rsslEncodeMsgComplete: { " "\"returnCode\": " << static_cast<signed> (rc) << "" ", \"enumeration\": \"" << rsslRetCodeToString (rc) << "\"" ", \"text\": \"" << rsslRetCodeInfo (rc) << "\"" " }";}
Feel free to take examples from my code, I also created a minimal ostream helpers for some additional types.
Yes, but it may not be informative, you are recommended to log all available data such as the return code, error code, error id, and error text as appropriate. Beware the value-add libraries have added their own error data types and return codes.
