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

[Question] Adding shared context for Result which presents in both Success and Error cases #536

Open
hankovich opened this issue Mar 28, 2024 · 1 comment

Comments

@hankovich
Copy link
Collaborator

I'm writing an important integration with a buggy third-party API that constantly changes its returning models. For debugging purposes and to be able to reprocess or replay its responses, I want to store plain responses along with some metadata like request duration. So, I'm looking for something like:

async Task<Result<Response, Error>> InvokeAsync()
{
    var firstResponse = await GetResponseAsStringAsync(...); // network call that returns raw API response, may fail
    var parsedFirstResponse = serializer.Deserialize<FirstResponse>(firstResponse); // may fail because API has weird contracts
    
    var secondResponse = await httpClient.GetStringAsync/* some parts of parsedFirstResponse */); // may fail
    var parsedSecondResponse = serializer.Deserialize<SecondResponse>(secondResponse); // may fail
}

And I want the Result I return to have some shared context in both success and error cases. In the case of success, it will have information about two successful responses, including their raw values and durations. In the case of failure, it will contain all available information (i.e., if processing fails during parsing, I want the Result to contain the raw response that caused parsing issues).

Has anyone ever faced such requirements before? I'm considering adding Result<T, TError, TContext> to my project.

@vkhorikov
Copy link
Owner

Sorry for late replies here.

This looks similar to the state monad (or maybe not, it's been awhile since I read that article). I would introduce a custom class to handle the intermediate result of the parsing and only use Result<T, E> at the edges of the parsing function. There's just too much going on during parsing and trying to cram all that into the "standard" Result won't do any good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants