-
-
Notifications
You must be signed in to change notification settings - Fork 760
Support ApiException.Content when actual type is ValidationApiException #953
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
Support ApiException.Content when actual type is ValidationApiException #953
Conversation
type is ValidationApiException. fixes reactiveui#636
Brilliant, thanks for this! I'll review shortly |
@jamiehowarth0 who else could give a review here? I'd like to see what y'all think of this change. |
Sorry for the delay, I'll check this in the next 24hrs |
@jamiehowarth0 ping! |
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.
Perfect, thanks!
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Fixes #636
Consider this usage of a Refit client:
If the response follows RFC 7808, then
e.Content
will unexpectedly benull
.This PR would change the behavior so that
e.Content
would still be set to the string content of the response message. If the exception is caught asValidationApiException
, thepublic ProblemDetails Content { get; }
will still function as normal.What kind of change does this PR introduce?
Enhancement: Support use of
ApiException.Content
when hidden byValidationApiException.Content
.What is the current behavior?
ApiException.Content
is left as default,null
, when hidden byValidationApiException.Content
.What is the new behavior?
ApiException.Content
is set to the string content of the response message.What might this PR break?
If consumers rely on
ApiException.Content
to benull
when the actual type isValidationApiException
, then their code may break. As far as I can tell, the alternative is more of an issue than this fix.Please check if the PR fulfills these r 8000 equirements
What docs should be added for this? I neglected this step because I considered the original behavior to be unexpected.