Does it make sense to declare a async method as private and then create a public method to act as a wrapper that calls the private method with ConfigureAwait(false)?

The intended purpose is design an intuitive API that hides complexities and doesn't require the user of the API to have to think about ConfigureAwait.

Is this called anything? Is it a design pattern?

Is this common?

public class Example
{
    public void Foo()
    {
        FooAsync().ConfigureAwait(false);
    }

    private async Task FooAsync()
    {
        // var x = await ...
        // Something(x);
    }
}
  • 2
    I don't think that this is a design pattern. I would call it a design decision. I think you should ask if hiding ConfigureAwait(false) as a default API behavior does present any danger. Also you can try asking it on stackoverflow.com. – lexeme Oct 11 at 10:25
  • ConfigureAwait affect following await. If there are no await, then it does nothing. – PetSerAl Oct 11 at 10:44
  • Did you miss something in copying? Your code does not make much sense.Your public method has no async anymore and does not await anything. It does not even call .Result. – nvoigt Oct 11 at 11:43
  • @nvoigt, No. The public method should not be async, as it uses ConfigureAwait(false). – Fred Oct 11 at 12:15
  • Why would you offer only a synchronous API, when that API is going to call async functions on the same object? I could understand giving both options, but not like this. – Bart van Ingen Schenau Oct 11 at 13:24

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.