Is your feature request related to a problem? Please describe.
ThingClients produce unhelpful HTTPX errors if something goes wrong. It is very hard to see if the arguments were wrong, or if something else went wrong in the action.
This makes testing difficult using ThingClient.
Describe the solution you'd like
It isn't going to be clear that the same type of error is possible, expecially if the server if defining custom errrors. I would create a new error like ThingClientInvocationError and report the message as read from the server, with the error type. This way you get:
ThingClientInvocationError: [TypeError] increment_by() is missing 1 required positional argument: 'value'
rather than:
httpx.HTTPStatusError: Client error '422 Unprocessable Entity' for url 'http://testserver/thing_name/increment_by'
This doesn't make it clear at all what is wrong.
The ThingClientInvocationError can have properties for debugging/testing:
server_error_type - returns a string such as ValueError
server_error_msg - just the error message
server_traceback - the traceback
It would also be possible to add something similar to pytest.raises into the labthings testing module (from lt.testing import server_raises) for testing:
with server_raises("TypeError", match="increment_by() is missing 1"):
thing_client.increment_by()
The downside of this is that sub-classed errors will not be matched.
Describe alternatives you've considered
It may be possible to capture known exception classes, such as ValueError, TypeError, RuntimeError etc. The benefit is that you can then write identical try-except cases in client code.
The downsides are:
- Some error classes will work and others wont which is bad logic. Having
ThingClientInvocationError should make it easy to see this is wrong on the server.
- The stack trace will be confusing because we cannot raise from a traceback for another instance of python.
Is your feature request related to a problem? Please describe.
ThingClients produce unhelpful HTTPX errors if something goes wrong. It is very hard to see if the arguments were wrong, or if something else went wrong in the action.
This makes testing difficult using ThingClient.
Describe the solution you'd like
It isn't going to be clear that the same type of error is possible, expecially if the server if defining custom errrors. I would create a new error like
ThingClientInvocationErrorand report the message as read from the server, with the error type. This way you get:ThingClientInvocationError: [TypeError] increment_by() is missing 1 required positional argument: 'value'rather than:
httpx.HTTPStatusError: Client error '422 Unprocessable Entity' for url 'http://testserver/thing_name/increment_by'This doesn't make it clear at all what is wrong.
The
ThingClientInvocationErrorcan have properties for debugging/testing:server_error_type- returns a string such asValueErrorserver_error_msg- just the error messageserver_traceback- the tracebackIt would also be possible to add something similar to
pytest.raisesinto the labthings testing module (from lt.testing import server_raises) for testing:The downside of this is that sub-classed errors will not be matched.
Describe alternatives you've considered
It may be possible to capture known exception classes, such as
ValueError,TypeError,RuntimeErroretc. The benefit is that you can then write identicaltry-exceptcases in client code.The downsides are:
ThingClientInvocationErrorshould make it easy to see this is wrong on the server.