Closed lawley closed 4 years ago
That is an interesting idea. The reason for the current behavior is that even though an OperationOutcome
is a good idea in a REST API, we are dealing with a Promise interface. When a promise is rejected, it has to be done with an Error
object.
However, what you are proposing makes sense. You are the first one to be interested in OperationOutcome
on the client side. I guess I can make it so that the OperationOutcome
object is attached to the error as an additional property, so that you can do:
client.request("Patient").catch(error => console.log(error.operationOutcome));
// or
try {
await client.request("Patient");
} catch (httpError) {
console.log(httpError.operationOutcome)
}
Is that what you were talking about?
Yes, exactly. In order to provide useful feedback to the user in my clients, access to the OperationOutcome like this is just what I need.
Great! This will be included in the next release, and if you use it as library (via script tag) you can give it a try now using the latest dev build from https://combinatronics.com/smart-on-fhir/client-js/master/dist/build/fhir-client.js.
The HttpError
is actually used in different situations and not only for the requests that the Client is making. For that reason, the new property of the error is called body
and can be an OperationOutcome
, a JSON object, a string or null
, depending on the server response. In your case, I think you can assume that what you get is an OperationOutcome
but if you use TypeScript, you might want to cast the body
property to fhirclient.FHIR.Resource
or fhirclient.JsonObject
first.
This is now included in the latest official release - 2.3.10
. Thank you!
While FHIR defines a OperationOutcome as a universal and reasonably useful machine-readable/processable result for errors, this library obfuscates it with the humanizeError function and the HttpError interface.
It would be very useful to expose a JSON error response through the HttpError interface.