Skip to content
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

Add NullableResponse<T> that Response<T> inherits from #27852

Closed
tg-msft opened this issue Mar 30, 2022 · 3 comments · Fixed by #31790
Closed

Add NullableResponse<T> that Response<T> inherits from #27852

tg-msft opened this issue Mar 30, 2022 · 3 comments · Fixed by #31790
Labels
Azure.Core Client This issue points to a problem in the data-plane of the library. DPG Mgmt This issue is related to a management-plane library.
Milestone

Comments

@tg-msft
Copy link
Member

tg-msft commented Mar 30, 2022

Response<T> requires that T Value is not null. When we want to work around that and return a Response<T> with no Value (like conditional requests that return 3XX, batching requests that haven't been sent to the service yet, DPG errors that were classified as success, ...) we usually throw when accessed. See NoBodyResponse and ErrorResponse as examples.

While that technically meets the contract for Response<T>, it doesn't match the spirit of it. We'd like to introduce a NullableResponse<T> that we can start using for this case. To avoid a bifurcated response hierarchy, we'd like to make the existing Response<T> inherit from it. Here's a rough example of what the API might look like:

public abstract class NullableResponse<T> {
    public abstract bool HasValue { get; }
    public abstract T Value { get;  }
    public abstract Response GetRawResponse() {}
}
 
public abstract class Response<T> : NullableResponse<T> {
     [EditorBrowsable(EditorBrowsableState.Never)]
     public override bool HasValue => true;
     public static implicit operator T(Response<T> response)
}

We also want to evaluate whether DPG protocol methods (and anything accepting RequestContext) should return this NullableResponse<T> instead of regular Response<T>.

@tg-msft tg-msft added Client This issue points to a problem in the data-plane of the library. Azure.Core DPG labels Mar 30, 2022
@annelo-msft annelo-msft self-assigned this Mar 30, 2022
@annelo-msft annelo-msft added this to the [2022] May milestone Mar 31, 2022
@annelo-msft
Copy link
Member

We also want to evaluate whether DPG protocol methods (and anything accepting RequestContext) should return this NullableResponse<T> instead of regular Response<T>.

DPG protocol methods only return Response, not Response<T>. It is the responsibility of the protocol method caller if they pass a response classifier saying errors are acceptable to check Response for errors in order to return a value that correctly matches the Convenience API return type without throwing an exception.

@annelo-msft annelo-msft modified the milestones: [2022] May, [2022] June Apr 6, 2022
@annelo-msft
Copy link
Member

Per offline conversation, this isn't required for DPG GA. We'll address it once we start adding the Get<Resource>IfExists methods to the management plane (after v1 GA) or to DPG.

@christothes
Copy link
Member

Note: This could affect any extensions to Response
guidelines

  • use nullableResponse when mainline scenario may not return a value
  • ETag scenarios : it depends

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Azure.Core Client This issue points to a problem in the data-plane of the library. DPG Mgmt This issue is related to a management-plane library.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants