Olá, Maurici!
Retornar um throw na API pode ser uma prática válida em alguns casos, pois permite que você informe detalhes sobre o erro ocorrido, como a linha e o arquivo onde ocorreu. No entanto, é importante considerar que essa abordagem pode expor informações sensíveis sobre a implementação da sua API, o que pode ser um risco de segurança.
Uma alternativa mais segura é utilizar o retorno de códigos de status HTTP adequados para indicar falhas ou negações na sua API. Por exemplo, você pode retornar um código 401 (Unauthorized) quando o usuário não estiver autenticado. Além disso, você pode incluir uma mensagem de erro no corpo da resposta, fornecendo informações úteis para quem está consumindo a API.
No seu exemplo, em vez de lançar uma exceção com a mensagem "Usuário não autenticado!", você poderia retornar um código 401 e incluir essa mensagem no corpo da resposta. Algo assim:
public async Task<ActionResult<string>> Login(LoginUsuarioDto dto)
{
var resultado = await _signInManager.PasswordSignInAsync(dto.Username, dto.Password, false, false);
if (!resultado.Succeeded)
{
return Unauthorized("Usuário não autenticado!");
}
var usuario = _signInManager
.UserManager
.Users
.FirstOrDefault(user => user.NormalizedUserName == dto.Username.ToUpper());
var token = _tokenService.GenerateToken(usuario);
return token;
}
Dessa forma, quem consumir a sua API receberá um código 401 e a mensagem "Usuário não autenticado!" no corpo da resposta, sem expor detalhes internos da implementação.
Dê uma olhada também no padrão Result é um padrão de mercado, ainda sem "formalização" de um livro, e acho que pode ser uma alternativa interessante também.
The Operation Result Pattern — A Simple Guide
FluentResults => Lib em .NET que ajuda a implementar o padrão Result
Result Object Pattern
The Operation Result Pattern
My take on the Result class in C#
Espero ter ajudado e bons estudos!
