Não há nada de errado em normalizar exceções e manipulá-las corretamente. Sua classe ErrorResponse
parece ser a abordagem correta para manipular uma chamada para seu serviço REST.
Se houver algo aqui que possa ser melhorado, é uma abordagem de tratamento de erros estáticos. A lista de possíveis exceções / códigos de erro pode facilmente crescer amanhã e o seu if else vai crescer para ser monstruoso nesse ritmo.
Considere criar uma classe ErrorManager
que contenha uma lista de ErrorHandler
interfaces com dois métodos: bool CanHandle(Exception)
e ErrorResponse Handle(Exception)
Seu ErrorManager
, quando receber uma exceção, verificará estupidamente cada ErrorHandler
registrado com uma chamada para CanHandle
, exceto a exceção. Quando ela retornar true, a verificação será interrompida e você retornará seu ErrorHandler
de chamar o método Handle
do seu manipulador. Em seguida, você cria um ErrorHandler
para cada possível ErrorResponse
(e não necessariamente para cada exceção).
Esta abordagem dinâmica oferece a flexibilidade para registrar programaticamente as classes ErrorHandler
ou carregá-las a partir de um banco de dados, se assim desejar. Mais importante do que isso, se você decidir registrar programaticamente as classes ErrorHandler
agora, caso decida alterar o modo de carregamento desses manipuladores, poderá fazê-lo com pouco ou nenhum impacto em seu programa como está. Em essência, você está protegendo o seu erro no futuro.
Uma palavra para o sábio: tenha um plano para quando você não encontrar nenhum manipulador para uma exceção. Provavelmente, é melhor deixar isso para ser um HttpStatusCode.InternalServerError
. Embora você possa criar um manipulador que "sempre lida" com exceções, eu aconselharia contra ele, já que tecnicamente estamos falando sobre o gerenciamento de exceções possíveis conhecidas e qualquer exceção que não é esperada é uma exceção desconhecida e certamente deve ser sinalizado de vermelho e não meramente tratado como qualquer outro erro.