Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft
Em um serviço ASP.NET Core, fora de manipuladores de evento, qual é o retorno apropriado para métodos assíncronos, considerando observação de exceções, possibilidade de await pelo chamador e boas práticas de escalabilidade?
APreferir ValueTask/ValueTask <T> em todos os métodos para reduzir alocações; quando o método apenas "dispara e esquece", usar async void para simplificar.
BReservar async void apenas para manipuladores de eventos; para métodos de serviço/repositório, retornar Task/Task <T>.
Cawait não bloqueia, mas em ASP.NET Core o contexto é sempre recapturado; por isso, ConfigureAwait(false) é obrigatório para evitar deadlocks.
DPara não "segurar" a thread de requisição, envolver todo I/O em Task.Run e retornar void quando não houver resultado.
ERetornar Task quando houver resultado e async void quando não houver, já que o chamador não precisa aguardar.
Revelar gabarito e comentário▾
GabaritoB — Reservar async void apenas para manipuladores de eventos; para métodos de serviço/repositório, retornar Task/Task <T>.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
ASP.NET Core — Métodos Assíncronos
Gabarito: letra B. A prática correta é reservar async void exclusivamente para manipuladores de eventos; métodos de serviço/repositório devem retornar Task ou Task<T>, permitindo que o chamador aguarde e observe exceções. Essa é a recomendação oficial da Microsoft para escalabilidade e tratamento de erros.
Alternativa A — ❌ Incorreta
Afirma que se deve preferir ValueTask/ValueTask<T> em todos os métodos, o que é excessivo — ValueTask é recomendado apenas quando o resultado é frequentemente síncrono ou em cenários de alto desempenho. Além disso, sugere usar async void para "dispara e esquece", prática perigosa que impossibilita a captura de exceções.
Alternativa B — ✅ Correta ⟵ GABARITO
Correta: async void deve ser limitado a event handlers (por exemplo, botão de clique em UI). Em camadas de serviço ou repositório, métodos assíncronos devem retornar Task/Task<T>, garantindo que o chamador possa await e tratar exceções adequadamente.
Alternativa C — ❌ Incorreta
Afirma que ConfigureAwait(false) é obrigatório em ASP.NET Core para evitar deadlocks. No ASP.NET Core, não há SynchronizationContext, portanto await não captura contexto de forma bloqueante — o uso de ConfigureAwait(false) é uma otimização opcional, não obrigatória. O erro é confundir com ASP.NET Classic (Web Forms), onde era crítico.
Alternativa D — ❌ Incorreta
Sugere envolver toda operação de I/O com Task.Run e retornar void. Task.Run destina-se a trabalho vinculado à CPU, não a I/O — para I/O usa-se diretamente os métodos assíncronos. Retornar void em métodos assíncronos não permite que o chamador aguarde nem observe exceções.
Alternativa E — ❌ Incorreta
Propõe retornar Task quando há resultado e async void quando não há. Novamente, async void só deve ser usado em event handlers. Para métodos sem retorno, o tipo correto é Task; o chamador que decide se aguarda ou não.
NÃO CAIA NESSA!
A alternativa C explora a confusão entre ASP.NET Classic e ASP.NET Core. Muitos candidatos lembram da regra do ConfigureAwait(false) como obrigatória do passado, mas no Core ela é apenas opcional. Fique atento ao ambiente mencionado.
Conclusão: Apenas a alternativa B está de acordo com as boas práticas para métodos assíncronos em ASP.NET Core.