Currently, when an RPC is sent, the response that comes back has its result code checked. If it is a SUCCESS or WARNINGS, the promise of the async function is resolved. Otherwise, it will reject the promise since the RPC failed. Because of this, failed RPC responses will have to be caught and handled inside the catch function. The problem comes in because this type of error will be conflated with other types of errors not related to the response being sent back, such as exceptions. This means that when the error is caught, it could either be an RPC response with a failed result code or some other exceptional error. If the promise resolves with any type of RPC response, then there can be a clear distinction of whether an RPC response was received, and catches can be set up in the calling functions to generally catch any other miscellaneous errors.
Bug Report
Currently, when an RPC is sent, the response that comes back has its result code checked. If it is a SUCCESS or WARNINGS, the promise of the async function is resolved. Otherwise, it will reject the promise since the RPC failed. Because of this, failed RPC responses will have to be caught and handled inside the catch function. The problem comes in because this type of error will be conflated with other types of errors not related to the response being sent back, such as exceptions. This means that when the error is caught, it could either be an RPC response with a failed result code or some other exceptional error. If the promise resolves with any type of RPC response, then there can be a clear distinction of whether an RPC response was received, and catches can be set up in the calling functions to generally catch any other miscellaneous errors.