This PR addresses two issues regarding error handling.
First, if request to Odoo fails with faultCode, current behavior is to simply return the fault code. This can be somewhat dangerous as there is no real indicator that an error even occurred. If user relies on API call to return an id of the record, he/she can mistakenly use the faultCode, without even knowing it happened. Instead, an exception should be thrown, preferably with faultString as message, to completely halt the process.
Second, if there is no connection to remote URL, the $http_response_header is never set, which leads to undefined variable error.
This PR addresses two issues regarding error handling.
First, if request to Odoo fails with
faultCode
, current behavior is to simply return the fault code. This can be somewhat dangerous as there is no real indicator that an error even occurred. If user relies on API call to return an id of the record, he/she can mistakenly use the faultCode, without even knowing it happened. Instead, an exception should be thrown, preferably withfaultString
as message, to completely halt the process.Second, if there is no connection to remote URL, the
$http_response_header
is never set, which leads to undefined variable error.