try catch finally 블록 내에서 돌아 오는 것은 나쁜 습관입니까?

try catch finally 블록 내에서 돌아 오는 것은 나쁜 습관입니까?

---

그래서 오늘 아침에 다음과 같은 코드를 보았습니다.

try
{
    x = SomeThingDangerous();
    return x;
}
catch (Exception ex)
{
    throw new DangerousException(ex);
}
finally
{
    CleanUpDangerousStuff();
}

이제이 코드는 정상적으로 컴파일되고 정상적으로 작동하지만 try 블록 내에서 돌아 오는 것이 옳지 않습니다. 특히 관련이있는 경우 특히 그렇습니다.

내 주요 문제는 마침내 자신의 예외를 던지면 어떻게됩니까? 반환 된 변수뿐만 아니라 처리해야 할 예외가 있습니다. 따라서 try 블록 내에서 반환하는 것에 대해 다른 사람들이 어떻게 생각하는지 알고 싶습니다.

---

아니요, 나쁜 습관이 아닙니다. return의미가있는 곳에 배치 하면 가독성과 유지 관리 성이 향상되고 코드를 이해하기가 더 쉽습니다. 명령문이 발생 finally하면 블록이 실행되므로 주의하지 않아도 return됩니다.

---

마지막은 무엇이든 상관없이 실행되므로 중요하지 않습니다.

---

개인적으로, 나는 마지막 진술 전에 반환 진술을보고 싶지 않다 때문에 이런 종류의 코딩을 피할 것입니다.

내 마음은 간단하고 오히려 선형으로 처리합니다. 따라서 드라이 런 코드를 살펴보면 일단 return 문에 도달하면이 모든 경우에 따르는 모든 것이 중요하지 않다고 생각하는 경향이 있습니다 (반환 문에 영향을 미치지는 않지만) 부작용이 무엇인지).

따라서 return 문이 finally 문 뒤에 항상 나타나도록 코드를 정렬합니다.

---

이 질문에 대한 답변

시도에서 실제로 일어나는 일 {return x; } 마지막으로 {x = null; } 진술?

그 질문을 읽음으로써 예외가 발생할 수 있다고 생각되면 finally 문에 다른 시도 catch 구조를 가질 수있는 것처럼 들립니다. 컴파일러는 언제 값을 반환할지 알아낼 것입니다.

즉, 나중에 코드를 혼동하지 않도록 코드를 재구성하는 것이 더 좋을 수도 있습니다.

---

기능적으로 차이는 없습니다.

그러나 이것을하지 않는 한 가지 이유가 있습니다. 종료 점이 여러 개인 더 긴 메소드는 종종 읽고 분석하기가 더 어렵습니다. 그러나 그 반대는 catch와 finally 블록보다 return 문과 더 관련이 있습니다.

---

귀하의 예에서 어느 쪽이든 동등합니다. 컴파일러가 동일한 코드를 생성하면 놀라지 않을 것입니다. finally 블록에서 예외가 발생하면 return 문을 블록에 넣거나 바깥에 넣을 때 같은 문제가 발생합니다.

실제 질문은 문체 적으로 가장 좋습니다. 하나의 return 문만 있도록 메서드를 작성하고 싶습니다.이 방법으로 메서드의 흐름을 쉽게 볼 수 있습니다. 따라서 return 문을 마지막에 놓아서 쉽게 볼 수 있습니다. 메소드의 끝과 이것이 리턴하는 것.

나는 return 문을 마지막 문장으로 깔끔하게 배치하면 다른 사람들은 여러 return 문을 메소드의 다른 부분에 뿌릴 가능성이 적습니다.

참고 URL : https://stackoverflow.com/questions/449099/is-it-bad-practice-to-return-from-within-a-try-catch-finally-block