Comentando declarações try catch

Question

O que é o lugar adequado para explicar o tratamento de erros em uma instrução try-catch? Parece que você poderia colocar comentários explicativos tanto no início do bloco try ou no bloco catch.

// Possible comment location 1
try
{   
    // real code
}
// Possible comment location 2
catch
{
    // Possible comment location 3

    // Error handling code

}

Answer 1

Eu costumo fazer o seguinte. Se há uma única exceção sendo tratado, eu normalmente não incomoda, uma vez que deve ser auto-documentação.

try
{   
    real code // throws SomeException
    real code // throws SomeOtherException
}
catch(SomeException se)
{
    // explain your error handling choice if it's not obvious
}
catch(SomeOtherException soe)
{
    // explain your error handling choice if it's not obvious
}

Answer 2

"Um comentário é uma mentira" . Trabalho sobre os nomes de variáveis ??e a lógica geral para que você possa evitá-lo. E se você realmente precisa mentir, fazê-lo dentro do bloco catch.

Answer 3

Eu não acho que é importante, em tudo.

Eu acho que a coisa importação para se lembrar com comentando é para o endereço por o código é a maneira como ele é e não o o código está fazendo, em primeiro lugar. Isso não quer dizer que você não deve explicar lógica complexa em um comentário conciso, mas o porquê é muito mais importante.

Answer 4

O que sobre apenas configurar o código para que ele não precisa de comentários extras?

try
{ 
   performDifficultAct( parameter );
}
catch (ArgumentOutOfRangeException couldNotFindArgument)
{
   // handle exception
}
catch (Exception otherUnknownException )
{
   // handle exception
}

Não há necessidade de documento, se você pode usar seu variável e método de nomeação para mostrar o que está acontecendo. Não há necessidade de documento, se você está tendo para fazer logon ou aumentar as exceções - a mensagem de registro no código fonte deve ser assim mesmo auto-explicativo. A única vez que você deve precisar de documentação extra em seu código é quando ele é totalmente não-óbvio o que o código está fazendo ou terapia é uma pegadinha-a fácil-miss ou passo ambígua você tem que adicionar a essa necessidade vontade explicação para qualquer um olhando para o código no futuro.

Edit: Para esclarecer um pouco, aqui está um pouco mais de como eu poderia usar essas declarações "pegar" para fornecer informações úteis tanto para um programador de manutenção e para usuários / support / QA / qualquer outra pessoa que usa o software. Também uma ilustração do tipo de situação onde eu absolutamente gostaria de adicionar comentários extras no código:

public void PerformSomeActionOrOther(string parameter)
{
  try
  { 
     // For some reason an eleven character string causes a bluescreen from Kernel32
     if (parameter.Length==11) parameter+=" ";

     performDifficultAct( parameter );
  }
  catch (ArgumentOutOfRangeException couldNotFindArgument)
  {
     this.Log.WriteLn("Argument out of range exception in ArbitraryClass.PerformSomeActionOrOther");
     this.Log.WriteLn(String.Format("Probable cause is that {0} is not in the array", parameter));
     this.Log.WriteLn(String.Format("Exception: {0}", couldNotFindArgument.Message));
  }
  catch (Exception otherUnknownException )
  {
     this.Log.WriteLn("Unexpected exception in ArbitraryClass.PerformSomeActionOrOther");
     this.Log.WriteLn(String.Format("Exception: {0}", otherUnknownException.Message));
     throw( otherUnknownException );
  }
}

Answer 5

Definitivamente não comentar o início da mesma, porque o que você pode ser útil para dizer, exceto "iniciar um tratamento de exceção do bloco aqui"? Comentários sobre as declarações de capturas são melhores, mas, em geral, mais uma vez, o que você vai dizer? "Lidar com uma NullPointerException"?

Eu iria para um comentário IFF é preciso dizer que você está fazendo algo emocionante, como encadeamento para uma exceção de aplicativo-domínio.

Answer 6

Eu acho que um bem escrito try / catch deve ser conciso e específico. Concordo com @ Jason que o por é mais importante, mas igualmente, é importante para manter o código dentro captura o mais conciso possível.

Ele também ajuda se você usou exceções específicas para ser capturado. Se você estiver usando Java, por exemplo, tentar pegar um NullPointerException em vez de uma exceção genérica. Isso deve explicar por que existe o try catch e que você está fazendo para resolvê-lo.

Answer 7

O local não importa, desde que você é consistente. Minha preferência pessoal é o seguinte:

//comment 1: code does XYZ, can cause exceptions A, B, C
try {
    //do something
}
//comment 2: exception A occurs when foo != bar
catch (ExceptionA a) {
    //do something
}
//comment 3: exception B occurs when bar is null
catch (ExceptionB b) {
    //do something
}
//comment 4: exception B occurs when foo is null
catch (ExceptionC c) {
    //do something
}

Answer 8

Eu sei que esta não é a resposta que você está procurando, mas não comentar nada. Se o seu código não é clara o suficiente para ficar em sua própria sem comentar, então você deve refatorar lo até que ele é. Jeffrey Palerm o escreveu apenas um Blog Post que os estados-la melhor.

Normalmente, os comentários tendem a documento ou:

• O código que é muito compacto. Coisas que se parecem com isto: ++i?--g:h-i;
• blocos longos de código que precisam ser resumido
• O código que é descartáveis ??ou não tem nenhuma razão clara para existente

Veja abaixo um exemplo simplificado de algumas simples comentando sobre o seu bloco de exceção, e uma versão que elimina a necessidade de comentários.

bool retries = 0;
while (retries < MAX_RETRIES)
{
    try
    {
        ... database access code
        break;
    }
    // If under max retries, log and increment, otherwise rethrow
    catch (SqlException e)
    {
        logger.LogWarning(e);
        if (++retries >= MAX_RETRIES)
        {
            throw new MaxRetriesException(MAX_RETRIES, e);
        }
    }
    // Can't retry.  Log error and rethrow.
    catch (ApplicationException e)
    {
        logger.LogError(e);
        throw;
    }
}

Enquanto os comentários acima promover a reutilização, você tem basicamente para manter tanto o código e os comentários. É possível (e preferível) para refatorar isso para que ele seja mais claro, sem comentários.

bool retries = 0;
while (canRetry(retries))
{
    try
    {
        ... database access code
        break;
    }
    catch (SqlException e)
    {
        logger.LogWarning(e);
        retries = incrementRetriesOrThrowIfMaxReached(retries, e);
    }
    catch (ApplicationException e)
    {
        logger.LogError(e);
        throw;
    }
}

...

private void incrementRetriesOrThrowIfMaxReached(int retries, Exception e)
{
    if (++retries >= MAX_RETRIES)
        throw new MaxRetriesException(MAX_RETRIES, e);

    return retries;
}

private bool canRetry(int retries)
{
    return retries < MAX_RETRIES;
}

O último exemplo pode parecer mais código para um benefício muito sutil, mas os ganhos não pode ser exagerada. O código é tão compreensível, mas você tem a vantagem de que você não precisa ter um conjunto separado de metadados (comentários), a fim de explicar o código. O código explica-se. Se o seu bloco de código captura é muito longo e precisa de comentário para resumir, penso sobre refatoração-lo para um método separado, a fim de melhorar a legibilidade.