You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
You are trying to throw an error that you never even imported #514
I totally disagree with this NonXMLResponseError error approach. The errors I am experience have to do with low level proxy, firewalls, certificates of authority, and NonXMLResponseError outright masks the error. These errors happen long before any communication has happened with Tableau Server.
Throw the root error, like you did in v0.8.1 and let the application developer make an intelligent choice. The "ServerResponseError.from_response" is a case of a library trying to do to much.
ServerResponseError will throw a ParseError if we revert this and you get a non-success code HTTP response that doesn't include our error-xml object. The ParseError throws an unhelpful 'couldn't parse at line1'.
Even in 0.8.1, we would just be returning a ParseError.
What information would you like passed through? The HTTP Response Body?
We can make a change here to improve it, but I need more detail on how you think the exception handling should flow. Would you be able to share an idea, either here or as a PR that I can review?
I took a look at the code, and it could be argued that the real issue starts athttps://github.com/tableau/server-client-python/blob/master/tableauserverclient/server/endpoint/exceptions.py#L17 where we blindly assume all response bodies will have an error object
Agreed, I pushed a fix in #515, it's in development now (where you can pull from to verify) -- we're discussing a patch release to master shortly as well.
Activity
dprophet commentedon Oct 23, 2019
I totally disagree with this NonXMLResponseError error approach. The errors I am experience have to do with low level proxy, firewalls, certificates of authority, and NonXMLResponseError outright masks the error. These errors happen long before any communication has happened with Tableau Server.
Throw the root error, like you did in v0.8.1 and let the application developer make an intelligent choice. The "ServerResponseError.from_response" is a case of a library trying to do to much.
t8y8 commentedon Oct 23, 2019
ServerResponseError will throw a ParseError if we revert this and you get a non-success code HTTP response that doesn't include our error-xml object. The ParseError throws an unhelpful 'couldn't parse at line1'.
Even in 0.8.1, we would just be returning a ParseError.
What information would you like passed through? The HTTP Response Body?
We can make a change here to improve it, but I need more detail on how you think the exception handling should flow. Would you be able to share an idea, either here or as a PR that I can review?
I took a look at the code, and it could be argued that the real issue starts athttps://github.com/tableau/server-client-python/blob/master/tableauserverclient/server/endpoint/exceptions.py#L17 where we blindly assume all response bodies will have an error object
Quick Fix for NonXMLErrorException (#515)
dprophet commentedon Oct 25, 2019
First thing is first. Fix the import on
https://github.com/tableau/server-client-python/blob/master/tableauserverclient/server/endpoint/endpoint.py#L1
You need to import NonXMLResponseError
t8y8 commentedon Oct 25, 2019
Agreed, I pushed a fix in #515, it's in development now (where you can pull from to verify) -- we're discussing a patch release to master shortly as well.
bcantoni commentedon Feb 22, 2021
I'm going to close this based on the end of the discussion where Tyler added the fix to import that error properly.
Quick Fix for NonXMLErrorException (tableau#515)