The current interface to the App API functions uses a completion callback with an optional AppError that indicates the success/failure of the operation. The internal functions bubble up a const reference to the Response from the server, which is translated to an AppError at the very top. This also means that errors generated during the processing usually either pass the Response object back to the top (and losing the context of the error) or generating a pseudo-Response object that contains the error.

Update these functions to either use the existing StatusWith<Response> class or something similar (AppErrorWith<Response>?) to allow bubbling up the errors more gracefully. Exceptions could possibly be used, but care must be taken to ensure the exception is not passed back up to the SDK "thread" that is calling the completion handler provided to the GenericNetworkTransport::send_request_to_server() function. The current AppError class may be desired to be kept, to reduce the SDK API changes and it contains additional fields the SDK users may be interested in (server logs URL, server_error string, and original http status code).

This will likely involve an SDK breaking change to the GenericNetworkTransport::send_request_to_server() to make the Response value an r-value && instead of a const reference so it can be {{std::move()}}ed without creating copies of the response data.

With the changes to App coming in from the update BaseUrl and Split out AppServices projects, these changes should probably wait until these projects are complete/nearly complete to avoid too many conflicts in the App class.