Exceções vs Códigos de resultados para uma classe cliente de soquete

Question

Eu tenho uma classe que encapsula TCP soquete comunicações com um servidor. Para cada mensagem de comando enviado para o servidor, o servidor irá enviar de volta uma mensagem de resposta que invariavelmente contém um código de resposta (OK, falha). Usando minha classe, cada comando pode ser executado tanto síncrona ou assíncrona.

Existem basicamente dois tipos de exceções que podem ocorrer: A "falta" que é causada por uma desconexão ou algum outro erro não-recuperável e uma exceção inesperada como "buffer de envio está cheio". No caso de uma falha, nenhum comando pode continuar ou tentar novamente ou qualquer coisa até que a conexão for restabelecida. No caso de uma resposta falha ou mesmo uma exceção, o comando pode ser julgado novamente ...

Então, agora os meus métodos de comando de sincronização retornar um enum que podem ter os seguintes valores: OK, falha, falha. Se ocorrer uma exceção, é simplesmente levantada para o segmento de chamada (em um comando sync). Para comandos assíncronos, o valor Resultado propriedade enum pode conter um valor extra: OK, falha, erro ou excepção eo retorno pode acessar o objeto de exceção real via Exception propriedade do objeto de comando

.

O que você acha sobre esta estratégia? Estou tentado a não levantar exceções em tudo para os comandos de sincronização e faça o login exceção internamente e retornar o valor enum quarta vez, porque isso é tudo que eu realmente vou fazer com exceções em qualquer caso dado de qualquer maneira ... Ou, eu não deveria estar usando os códigos de resultado em tudo e só exceções aumento de todos os casos, até mesmo falhas?

Graças.

Answer 1

Eu acho que a sua estratégia é basicamente som.

Tenha em mente que o propósito de Exceções é lidar com condições excepcionais. Quanto mais próximo da origem do problema, melhor.

No seu caso, parece que a sua estratégia é algo como "Não deu certo agora. Vamos repetição". Eu não vejo uma razão para realmente exceções aumento.

Se lidar com um soquete fechado era algo que exigia um fluxo totalmente diferente no seu código, então talvez exceções faria sentido. De sua descrição, isso não é realmente o caso.

Minha filosofia em Exceções é que eles devem ser para condições excepcionais que você não pode realmente lidar com eles. Um soquete fechado? Hmm ... quantas vezes é que a internet vai para baixo em minha casa ...

Answer 2

A minha preferência é que você lançar uma exceção a qualquer momento o seu método não concluir com êxito a sua missão. Então, se eu, o chamador, chame yourObject.UploadFile (), vou assumir que o arquivo foi enviado com sucesso quando a chamada retorna. Se falhar, por qualquer motivo, espero que o objeto irá lançar uma exceção. Se você quiser fazer a distinção entre os comandos que posso repetir e comandos que não deveria repetição, colocar essa informação na exceção e posso decidir como reagir em conformidade.

Ao chamar yourObject.BeginAsyncUploadFile (), eu esperaria o mesmo comportamento, exceto que eu preciso esperar para o IAsyncResult ou objeto equivalente para descobrir se o upload do arquivo bem-sucedida ou não, e em seguida, verificar uma exceção / Erro propriedade, se isso não aconteceu.

Answer 3

Códigos de resultado e exceções tanto pode funcionar bem. É uma questão de gosto pessoal (e o gosto dos outros em sua equipe). Exceções têm algumas vantagens, especialmente em ambientes mais complexos, mas em sua configuração que parece simples o suficiente para que os códigos de retorno deve funcionar bem.

Algumas pessoas vão espumar pela boca e insistem em exceções, mas no meu projeto pessoas como a simplicidade de códigos de retorno, tornando-a melhor escolha geral.

Answer 4

Esta é uma pergunta muito interessante. Como tal, não há provavelmente nenhuma resposta '100% correto', e na maior parte depende de como você acha que o código usando a sua função deve ser estruturado.

A maneira que eu vejo é você usar exceções apenas quando você deseja fornecer o código de chamada a sua função com uma maneira de escapar graciosamente de uma situação 'desastrosa'. Então, no meu código que eu normalmente lançar uma exceção quando algo realmente, realmente horrível acontece, e as necessidades do chamador saber.

Agora, se o que você tem é uma normal e esperado, situação que você provavelmente deve retornar um valor de erro. Dessa forma, o código sabe que precisa 'tentar mais difícil', mas não será comprometida com o que aconteceu.

No teu caso, por exemplo, você poderia tratar os tempos de espera como algo esperado, e, portanto, retornar um código de erro e problemas mais graves (como um buffer de envio completo) onde as chamadas necessidades de código para executar algumas ações extras para voltar para 'normal' como uma exceção.

Mas, em seguida, a beleza está nos olhos de quem vê, e algumas pessoas vão dizer-lhe para únicas exceções de uso, outros (a maioria programadores C) para apenas códigos de uso de retorno. Basta lembrar, exceções devem sempre ser excepcional. :)