댓글 작성 시도 캐치 문

StackOverflow https://stackoverflow.com/questions/413985

  •  03-07-2019
  •  | 
  •  

문제

Try-Catch 문서에서 오류 처리를 설명하기에 적절한 장소는 무엇입니까? 시도 블록의 시작 또는 캐치 블록의 시작에 설명적인 의견을 넣을 수있는 것 같습니다. 

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

    // Error handling code

}
도움이 되었습니까?

해결책

나는 보통 다음을 수행합니다. 처리되는 예외가 단 하나 뿐인 경우, 자체 문서화해야하므로 귀찮게하지 않습니다.

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
}

다른 팁

"댓글은 거짓말입니다". 변수 이름과 일반 논리를 피하여 피할 수 있습니다. 그리고 당신이 정말로 거짓말을해야한다면, 캐치 블록 안에서 그것을하십시오.

나는 그것이 중요하다고 생각하지 않습니다.

주석으로 기억해야 할 수입은 왜 코드는 그렇지 않은 방식입니다 무엇 코드는 무엇보다도 최우선입니다. 이것은 간결한 의견에 복잡한 논리를 설명해서는 안된다는 것이 아니라 그 이유가 훨씬 더 중요합니다.

추가 주석이 필요하지 않도록 코드를 설정하는 것은 어떻습니까?

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

변수 및 메소드 명명을 사용하여 무슨 일이 일어나고 있는지 표시 할 수있는 경우 문서화 할 필요가 없습니다. 예외를 기록하거나 제기 해야하는 경우 문서화 할 필요가 없습니다. 소스 코드의 로깅 메시지는 어쨌든 자명해야합니다. 코드에서 추가 문서가 필요한 유일한 시간은 코드가 수행하는 일이 전혀 불가능한시기입니다. 앞으로 코드.

편집 : 조금 명확히하기 위해, 여기에 "캐치"진술을 사용하여 유지 보수 프로그래머와 소프트웨어를 사용하는 다른 사람에게 유용한 정보를 제공하는 방법에 대해 조금 더 있습니다. 또한 코드에 추가 주석을 추가하고 싶은 상황의 그림.

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 );
  }
}

"여기에서 예외 처리 블록을 시작하는 것"을 제외하고는 무엇을 유용하게 말할 수 있습니까? 캐치 진술에 대한 의견이 더 좋지만 일반적으로 다시 말하면 무엇을 말 하시겠습니까? "NullPointerException 처리"?

나는 당신이 애플리케이션 도메인 예외에 대한 연쇄와 같은 흥미 진진한 일을하고 있다고 말할 필요가 있다면 의견을 간다.

잘 쓰여진 시도/캐치는 간결하고 구체적이어야한다고 생각합니다. 나는 @jason에 동의합니다 왜 더 중요하지만 동일하게 코드를 가능한 한 간결하게 유지하는 것이 중요합니다.

구체적인 예외를 사용하여 잡히면 도움이됩니다. 예를 들어 Java를 사용하는 경우 일반적인 예외가 아닌 NullPointerException을 찾으십시오. 이것은 시도 캐치가 존재하는 이유와 그것을 해결하기 위해 무엇을하고 있는지 설명해야합니다.

위치는 당신이 일관성있는 한 중요하지 않습니다. 내 개인적인 취향은 다음과 같습니다.

//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
}

나는 이것이 당신이 찾고있는 대답이 아니라는 것을 알고 있지만 전혀 언급하지 마십시오. 코드가 댓글을 달지 않고 스스로 견딜 수있을만큼 명확하지 않은 경우, 언제까지도 리팩터링해야합니다. Jeffrey Palermo 방금 썼다 블로그 게시물 그것은 그것을 가장 잘 말합니다.

일반적으로 의견은 다음 중 하나를 문서화하는 경향이 있습니다.

  • 너무 컴팩트 한 코드. 다음과 같이 보이는 것 : ++i?--g:h-i;
  • 요약 해야하는 긴 코드 블록
  • 일회용 또는 기존에 대한 명확한 이유가없는 코드

예외 블록에 대한 간단한 주석에 대한 단순화 된 예제와 주석이 필요하지 않은 버전은 아래를 참조하십시오.

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;
    }
}

위의 의견은 재사용 성을 촉진하지만 본질적으로 코드와 의견을 모두 유지해야합니다. 댓글없이 명확하게하기 위해 이것을 리팩터링하는 것이 가능하고 선호됩니다.

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;
}

후자의 예는 매우 미묘한 혜택을위한 더 많은 코드처럼 보일 수 있지만 이익은 과장 될 수 없습니다. 코드는 이해할 수 있지만 코드를 설명하기 위해 별도의 메타 데이터 세트 (주석)가 필요하지 않다는 이점이 있습니다. 코드는 자체를 설명합니다. 캐치 코드 블록이 너무 길고 요약하려면 주석이 필요한 경우 가독성을 향상시키기 위해 별도의 방법으로 리팩토링에 대해 생각해보십시오.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top