|
except requests.HTTPError as e: |
Current design makes it difficult to distinguish error responses from success responses
Either way the client just returns a dictionary
So we have to sniff the fields to see if it "looks like" an error or a success response
But there are problems with that, e.g. https://docs.voucherify.io/reference/errors error body contains a code field, but Get Voucher success response also contains a code field https://docs.voucherify.io/reference/the-voucher-object
error response also has message and details but I wouldn't be surprised if there are success responses that contain those too
A better design would be for the client to raise an exception if error response is received. The exception instance can still have the parsed json error body attached. That way users of the client could trivially distinguish error from success.
voucherify-python-sdk/voucherify/client.py
Line 36 in 090ad70
Current design makes it difficult to distinguish error responses from success responses
Either way the client just returns a dictionary
So we have to sniff the fields to see if it "looks like" an error or a success response
But there are problems with that, e.g. https://docs.voucherify.io/reference/errors error body contains a
codefield, but Get Voucher success response also contains acodefield https://docs.voucherify.io/reference/the-voucher-objecterror response also has
messageanddetailsbut I wouldn't be surprised if there are success responses that contain those tooA better design would be for the client to raise an exception if error response is received. The exception instance can still have the parsed json error body attached. That way users of the client could trivially distinguish error from success.