Exceções ou códigos de erro


12

Estamos construindo um serviço da Web (SOAP, .Net) que falaria com (principalmente) clientes nativos (Windows, C ++) e estamos imaginando qual é a melhor maneira de comunicar erros ao cliente (por exemplo, SomethingBadHappened, como o serviço de login não disponível ou algo como usuário não encontrado) e não conseguiu decidir entre lançar uma exceção para o cliente ou usar algum tipo de modelo de código de erro para fazer o acima.

O que você preferiria no tratamento no lado do cliente: receber um código de erro ou manipular uma exceção ServerFault que contenha o motivo do erro?
1) Por que estamos pensando em exceção: porque tornaria o código do lado do servidor muito mais uniforme
2) Por que estamos pensando em códigos de erro: Porque pensamos que faz mais sentido do ponto de vista do cliente.

Se 2) for realmente verdade, provavelmente quereríamos procurar códigos de erro do que exceções? É esse o caso aqui?

Além disso, a resposta mudaria se estivéssemos conversando com clientes gerenciados em vez de clientes nativos?


Apenas para adicionar um pouco de esclarecimento: a) Estou procurando as melhores práticas aqui e a experiência do lado do cliente (já que o cliente é muito mais complicado e preferimos lidar com as coisas do lado do servidor se podemos manter o código do cliente mais simples) b) O cliente contém muitos códigos herdados e podemos ou não ser capazes de usar exceções em C ++.
Amit Wadhwa

Isso pode ajudar- www.codeproject.com/KB/cpp/cppexceptionsproetcontra.aspx
Gulshan

Respostas:


8

O SOAP tem um conceito de falhas , você pode converter uma exceção em uma falha no lado do servidor e, no proxy do cliente, a falha pode ser novamente convertida em uma exceção. Isso funciona notavelmente bem na pilha metro do WCF e Java, não pode comentar em clientes C ++ nativos.

No que diz respeito às práticas recomendadas de SOA, defina uma falha genérica e poucas falhas específicas apenas se o cliente precisar tratar um determinado tipo de erro de maneira diferente. Nunca envie um rastreamento de pilha de exceção para o cliente na implantação de produção. Isso ocorre porque, em teoria, o rastreamento do servidor não tem significado para o cliente e também por razões de segurança. Registre o erro completo e o rastreamento de pilha no servidor e envie uma referência exclusiva ao log na falha. No WCF, uso o bloco Microsoft Exception Handling da Enterprise Library para gerar um guia e também converter uma exceção em falha SOAP.

Verifique as orientações em Microsoft Patterns and Practices .


Graças isso parece bom. Você pode me dar um link mais específico lá dentro da página lá.
Amit Wadhwa

Também o que sobre erros de nível de negócios como UserNotFound etc, devem estes também ser tratadas como exceções
Amit Wadhwa

Nos projetos anteriores, nunca usamos Exceções no código ou Falhas no SOAP para comunicar modos de falha legítimos / esperados. Usamos códigos de erro e os deixamos ao cliente para decidir o que fazer com eles. O usuário não encontrado não é realmente um erro / exceção, provavelmente deve ser um código de status.
MrLane

4

Recentemente, eu fiz um serviço da web com as bibliotecas Java 6, que pode relatar uma exceção de volta ao chamador (não examinei como isso é feito automaticamente).

A capacidade de fazer com que o cliente forneça um rastreamento de pilha no relatório de erros para o desenvolvedor tem sido muito útil (em vez de obter um carimbo de data / hora aproximado e depois procurar em seus logs, se você o registrar).

Portanto, visto do ponto de vista dos desenvolvedores, use Exceções.


1
Concordo que isso pode ser útil em dogfood e beta, mas você realmente deseja espalhar rastreamentos de pilha em logs de eventos ou arquivos de log em uso no mundo real (e, claro, revelando mais detalhes sobre o serviço do que você precisa / deseja no processo )
Amit Wadhwa

2
@ Aceite, confie em mim: se você encontrar uma situação que dê um rastreamento de pilha na produção, você QUER o rastreamento de pilha!

1
Qual é o benefício no rastreamento de pilha no lado do cliente? Definitivamente, registraremos todas as exceções no lado do servidor antes de repassá-las ao cliente.
Amit Wadhwa

Também o que sobre erros de nível de negócios como UserNotFound etc, devem estes também ser tratadas como exceções
Amit Wadhwa

-2

Se for um serviço da Web, você não poderá exatamente fazer com que o servidor lance uma exceção que será capturada pelo cliente. Na interface, seu servidor basicamente precisa retornar algum tipo de código de erro, mesmo que seja uma string que diz An exception occurred. Type %s, message %s, stack trace %s.

Quanto ao lado do cliente, seu código de leitura de resposta pode verificar a resposta para ver se ele contém um erro e gerar uma exceção no lado do cliente. Essa é uma maneira muito boa de fazer isso, em idiomas com pelo menos um bom tratamento de exceções. O C ++, no entanto, não possui boas exceções de manipulação e é uma boa ideia ficar o mais longe possível das exceções do C ++. Se você não pode usar um idioma melhor, siga apenas os códigos de erro.


Eu acho que a exceção não capturada iria tão ServerFault para o cliente
Amit Wadhwa

3
Não há nada errado com as exceções C ++ ou C ++. Existem várias razões para usar uma linguagem diferente do C ++ para certos projetos, mas o tratamento de exceções não é um deles.
KeithB

Não apenas isso é contra as práticas recomendadas de segurança: o que exatamente o cliente deve fazer com o rastreamento de pilha do seu servidor? Imprima e envie para você? Enviar como email? Use para papel lubrificante?
JensG

@JensG: Se este é um serviço da Web e não um site , o cliente deve ser profissional o suficiente para enviá-lo por e-mail como um relatório de erro.
Mason Wheeler
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.