-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include more details in the ApiConnectionException message #316
Include more details in the ApiConnectionException message #316
Conversation
Codecov Report
@@ Coverage Diff @@
## main #316 +/- ##
==========================================
+ Coverage 94.34% 94.47% +0.13%
==========================================
Files 8 8
Lines 796 797 +1
==========================================
+ Hits 751 753 +2
+ Misses 45 44 -1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks as expected. Only thing we might want to consider is including the actual failing request/response as properties of the exception, things like headers are likely to be helpful with debugging auth issues.
Renaming |
That's a very good point. We could leave it as 'message', but it will be a bit confusing that it essentially repurposes the base exception keyword argument. We might not have a choice though. I might argue that there are no actual packages that are using |
Changes should now be non-breaking. I haven't added the actual response object to the exception itself, my rationale being that it's another arg (that in reality could replace 3 of them, but not if we want a non-breaking change), and that if you're actually trying to fix the issue, it's trivial to just step up one level in the call stack to see what the problem is. |
After further discussion/thinking, we've decided to go ahead with breaking changes, and the response object is now the only thing passed to the exception. Extraction of relevant information is now handled in the exception itself. |
…ps://github.com/pyansys/openapi-common into feat/313-improve-ApiConnectionException-message
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
* Include more details in the ApiConnectionException message * Content might be empty * Make changes non-breaking * Use response object * Check exception repr * Run black * Fix integration test * Test initial response handler
Closes #313
Improves the message included in an ApiConnectionException to include all the information that is passed into the exception constructor, instead of just the response from the server.
Also adds the URL that resulted in the exception, resulting in a stack trace that looks like this:
In some cases the content returned by the server would have been enough to figure out the cause of the issue, but not always. We now always raise an exception with at least the following:
If any content was returned by the server, it is also included in the exception.