Pergunta

Eu tenho o seguinte código em uma classe da mina. O objetivo desta classe é obter o equilíbrio de um servidor web. Apenas no caso de algo der errado com a obtenção do equilíbrio. Vou lidar com uma exceção. No entanto, tudo isso é fácil de fazer. Mas eu fiquei me perguntando o que eu volte em minha declaração de captura.

A maioria dos exemplos que eu olhei para apenas escrever para o console usando:

Console.WriteLine(ex.Message);

Isso é tudo muito bem. Mas em uma aplicação real o que fazer a maioria dos desenvolvedores fazer?

 //Download only when the webclient is not busy.
        if (!wc.IsBusy)
        { 
            // Sleep for 1/2 second to give the server time to update the balance.
            System.Threading.Thread.Sleep(500);

            try
            {
                // Download the current balance.
                wc.DownloadStringAsync(new Uri(strURL));
            }
            catch (WebException ex)
            {
                Console.Write("GetBalance(): " + ex.Message);
            }
        }
        else
        {
            Console.Write("Busy please try again");
        }

A minha função no momento retorna void. E eu estou me perguntando o que mais eu gostaria de voltar se o webclient está ocupado?

Muito obrigado por qualquer conselho,

Foi útil?

Solução

não pegar uma exceção se você não pode lidar com isso. Se você retornar apenas algum valor, o método de chamada tem de verificar se o valor é um resultado real ou apenas um indicador de uma exceção. E agora este método deve decidir o que fazer e retorno. E o método de chamar esse método. E o método ...

Então, basta deixar a bolha exceção a pilha e pegá-lo em algum lugar onde você pode lidar com isso. Talvez diretamente abaixo da interface do usuário e, em seguida, exibir uma caixa de mensagem perguntando se o usuário deseja repetir ou exibir informações como resolver o problema. Se você não tem interface de usuário, pegá-lo em algum lugar onde você pode resolver o problema e tente novamente. Se é um problema temporário, tente novamente toda a tarefa em um nível razoável até que a chamada for bem-sucedido.

Se você quiser registrar algo, use o seguinte padrão para registrar a exceção de um relançar-lo.

try
{
   DoStuff();
}
catch (Exception exception)
{
   Log(exception.ToString());

   throw;
}

Note que é throw; e não throw exception;. Se você fazer o mais tarde, você perde o rastreamento de pilha originais. Se você pode inferir mais detalhes sobre a causa da exceção, você deve envolver a exceção capturada em uma exceção mais significativa com informações adicionais.

try
{
   DoStuff();
}
catch (SpecificMeaninglessException exception)
{
   Log(exception.ToString());

   throw new MeaningfulException("Details about the error.", exception);
}
catch (Exception exception)
{
   Log(exception.ToString());

   throw;
}

Outras dicas

Você deve usar o método () ex.ToString

Exception.Message contém uma descrição simples da exceção (por exemplo "referência de objeto não definida ...").

Exception.ToString () contém uma descrição da exceção, juntamente com um rastreamento de pilha completa.

Tratamento de exceção Melhores Práticas em .NET

Você poderia re-executar o método se o cliente está ocupado, mas esperar um certo tempo antes de tentativas? Potencialmente com uma falha após x tentativas.

Se em vez disso você deseja seguir em frente e simplesmente registrar o problema, a sua declaração de captura poderia registrar a exceção para um registro baseado em arquivos, visualizador de eventos, submeter-se a um banco de dados, criar um alerta (e-mail, sms, etc.) se é necessário.

Depende da gravidade da exceção.

Eu sugeriria olhar para exceção Bloco de Padrões e Práticas

Se você está interessado apenas em ver a exceção você deve re lançar a exceção de modo que-já está pensando em lidar com ele ainda vai obtê-lo.

Você certamente não quer mascarar uma exceção não tratada. Deixe que a borbulhar através da pilha. Mas se você está perguntando o que a retornar se o cliente web é apenas ocupado, como sobre retornando quer um intervalo aleatório ou algum intervalo significativo que a função chamador deve aguardar antes de tentar baixar o equilíbrio novamente? Um número aleatório poderia distribuir carga ou de outra forma reduzir um problema de colisão. Um intervalo mais significativo poderia ser enviado de volta com base no estado atual do servidor.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top