serviços web devem lançar exceções ou objetos de resultado

Question

Eu não tenho certeza que estou completamente feliz que lançar exceções em serviços web é uma boa idéia. Eu não me importaria tanto se não fosse para o rastreamento de pilha. Isso não é algo que eu wan't.

Eu pesquisei em torno de várias implementações e não há realmente não parece haver um consenso sobre isso. CampaignMonitor por exemplo, faz retornar um objeto de resultado, mas outros não.

Arquitetonicamente, eu não estou certo de retornar um objeto de retorno faz sentido, certamente uma exceção é uma exceção, mas o que eu gosto sobre um objeto de retorno é que é uma solução mais elegante para o usuário final.

Alguém tem alguma solução melhor?

Editar

BTW eu estou usando serviços web ASMX, onde transformando CustomErrors não é uma opção.

Answer 1

O rastreamento de pilha que você está falando? Você já tentou isso?

Em ambos os serviços ASMX e WCF, uma exceção não pega vai ser traduzido em uma falha SOAP. Em ambos os casos, eles podem ser configurados para não incluir qualquer vestígio pilha. Na verdade, esse é o padrão no WCF.

Assim, a maneira correta de retornar um erro como este é através de uma falha. Uma maneira de gerar falhas é jogar e não lidar com uma exceção.

Answer 2

Não deixe que o fato de que você está em um serviço web confundir a questão. Isso é apenas um detalhe de implementação.

Use a sua estratégia normal de manipulação de exceção. Melhores práticas diz não exceções armadilha em código de baixo nível - a menos que você pode resolver essa exceção lá e continuar normalmente. Exceções devem ser levantadas para a camada de apresentação para que o usuário pode ser informado do erro.

Assim, quando aplicado a serviços web - em exceções gerais do throw (que resulta em uma SoapFault). Isso permite que o código do cliente invocando a usá-lo está embutido manipulação de exceção padrão para manuseá-lo.

Answer 3

Uma abordagem é a de erros de sistema e de negócios separados. . (Erro de sistema: pedido por exemplo malformado, user-não-autorizada, etc .; erro de negócios: por exemplo UpdateCars método resulta em um erro, o usuário não possua quaisquer carros)

Em caso de um erro de negócio, retornar um objeto de resposta contendo uma descrição de erro; no caso de um erro de sistema, lançar uma exceção.

Answer 4

Você pode esclarecer um pouco? A do lado do servidor de um serviço web pode lançar uma exceção. A do lado do servidor de um serviço web pode retornar uma mensagem para o lado do cliente. Essa mensagem pode conter informações de erro, e que a informação de erro pode especificamente incluir detalhes de exceção. Ou talvez não. No lado do cliente, você normalmente tem um proxy gerado para lidar com a mensagem do servidor. Este proxy pode gerar uma exceção se que a resposta contém informações de erro.

Qual parte deste cenário que você está perguntando sobre?

Answer 5

Suponho que lançar exceções é em geral um padrão de design melhor, em seguida, retornar um resultado. Suponho que você tem a fazer é dentro de seus serviços web para rastrear hide pilha aplicando o seguinte padrão para cada método exposto como serviço web:

MyWebServiceMethod public void () {
tente
{

 ///Do something that may cause an error

} catch (Exception ex)
{ throw new ApplicationException ( "User friendly descritption de exceção ");

}

}

ou você também pode

catch (Exception ex) { jogue ex; }

Se você re-lançar uma exceção, você vai esconder rastreamento de pilha original dos clientes de seus serviços web.

Answer 6

Eu não vejo por que você não pode fazer as duas coisas? Capturar a exceção, registrá-lo (seja para um DB ou para um arquivo), em seguida, retornar um código de erro. Dessa forma você terá uma execução graciosa da chamada webservice, e também a notificação do erro, e você tem um local em outro lugar você pode ainda depuração.