캐치 절없이 try ...를 사용하는 이유는 무엇입니까?

프로그래밍하는 고전적인 방법은입니다 try ... catch. try없이 사용하는 것이 언제 적절 catch합니까?

파이썬에서 다음은 합법적으로 보이며 의미가 있습니다.

try:
  #do work
finally:
  #do something unconditional

그러나 코드는 catch아무것도 하지 않았습니다 . 마찬가지로 Java에서는 다음과 같이 생각할 수 있습니다.

try {
    //for example try to get a database connection
}
finally {
  //closeConnection(connection)
}

좋은 것처럼 보이고 갑자기 예외 유형 등에 대해 걱정할 필요가 없습니다. 이것이 좋은 습관이라면 언제 좋은 습관입니까? 또는 이것이 좋은 습관이 아니거나 합법적이지 않은 이유는 무엇입니까? (소스를 컴파일하지 않았습니다. Java에 대한 구문 오류 일 수 있으므로 묻습니다. Python이 반드시 컴파일되는지 확인했습니다.)

내가 겪은 관련 문제는 이것입니다 : 함수 / 메소드를 계속 작성하고 끝에 무언가를 반환해야합니다. 그러나 도달해서는 안되는 장소에있을 수 있으며 귀환 지점이어야합니다. 따라서 위의 예외를 처리하더라도 NULL코드의 특정 지점에 도달하지 않아야하는 빈 문자열을 반환 합니다. 종종 메서드 / 함수의 끝입니다. 항상 코드를 재구성하지 않아도되도록 코드를 재구성 return NULL했습니다.

이 시점에서 발생할 수있는 예외를 처리 할 수 ​​있는지 여부에 따라 다릅니다.

예외를 로컬에서 처리 할 수 ​​있으면 가능한 한 오류가 발생한 위치에 가깝게 오류를 처리하는 것이 좋습니다.

로컬로 처리 할 수 ​​없다면 try / finally블록이 있으면 완벽하게 합리적입니다. 메소드가 성공했는지 여부에 관계없이 실행 해야하는 코드가 있다고 가정합니다. 예를 들어 ( Neil의 의견에서 ) 스트림을 열고로드 할 내부 메소드로 스트림을 전달하는 try { } finally { }것은 finally 절을 사용하여 성공 또는 읽기 실패.

그러나 응용 프로그램을 완전히 중단시키지 않으려면 코드 어딘가에 예외 처리기가 여전히 필요합니다 . 해당 핸들러가있는 애플리케이션의 아키텍처에 따라 다릅니다.

이 finally블록은 오류 조건 (예외)이 발생했는지 여부에 관계없이 항상 실행해야하는 코드에 사용됩니다.

finally블록 의 코드는 블록이 try완료된 후 실행 되며 예외가 발생하면 해당 catch블록이 완료된 후 실행 됩니다. try또는 catch블록 에서 포착되지 않은 예외가 발생한 경우에도 항상 실행 됩니다.

finally블록은 일반적으로 개방 된 기타 폐쇄 파일, 네트워크 접속에 사용되는 try블록. 그 이유는 파일 또는 네트워크 연결을 사용한 작업의 성공 여부에 관계없이 파일 또는 네트워크 연결을 닫아야합니다.

finally블록 자체에서 예외가 발생하지 않도록 주의해야합니다 . 예를 들어 null, 등의 모든 변수를 확인해야합니다 .

Java 에서 try ...가 catch 절이없는 try (최종의 관용어 ) 가 적합한 예 는 동시 유틸리티 locks 패키지에서 Lock 을 사용하는 것입니다 .

• API 문서 에서 설명하고 정당화하는 방법은 다음과 같습니다 (따옴표로 묶은 글꼴은 내 것입니다).
  

  ... 블록 구조 잠금이 없으면 동기화 된 메소드 및 명령문에서 발생하는 자동 잠금 해제가 제거됩니다. 대부분의 경우 다음 관용구를 사용해야합니다 .

   Lock l = ...;
   l.lock();
   try {
       // access the resource protected by this lock
   } finally {
       l.unlock();
   }

  잠금 및 잠금 해제가 다른 범위에서 발생하는 경우 잠금이 유지되는 동안 실행되는 모든 코드가 try-finally 또는 try-catch 에 의해 보호되어 필요할 때 잠금이 해제되도록주의해야합니다 .

기본적인 수준에서 catch와 것은 finally두 개의 관련된하지만 서로 다른 문제를 해결 :

• catch 호출 한 코드로보고 된 문제를 처리하는 데 사용됩니다.
• finally 문제가 발생했는지 여부에 관계없이 현재 코드가 작성 / 수정 한 데이터 / 자원을 정리하는 데 사용됩니다.

그래서 둘 다 문제 (예외)에 어떻게 든 관련이 있지만 공통점은 거의 모든 그들이 가지고있다.

중요한 차이점은 finally블록 이 리소스 누수를 피하기 위해 리소스를 생성 한 것과 동일한 방법으로 호출 스택에서 다른 수준으로 놓을 수 없다는 것입니다.

은 catch그러나 다른 문제이다 : 그것을위한 올바른 위치에 따라 달라집니다 당신이 실제로 처리 할 수있는 예외를. 아무것도 할 수없는 곳에서 예외를 잡는 데는 아무 소용이 없기 때문에 간과하는 것이 더 나은 경우가 있습니다.

@yfeldblum은 정답이 있습니다. catch 문이없는 try-finally는 일반적으로 적절한 언어 구문으로 대체해야합니다.

C ++에서는 RAII와 생성자 / 소멸자를 사용합니다. 파이썬에서 이것은 with진술입니다. 그리고 C #에서는 using진술입니다.

초기화 및 종료 코드가 두 곳이 아닌 한 곳 (추상화 된 객체)에 있기 때문에 이들은 거의 항상 더 우아합니다.

많은 언어에서 finally명령문은 return 문 다음에 실행됩니다. 즉, 다음과 같은 작업을 수행 할 수 있습니다.

try {
  // Do processing
  return result;
} finally {
  // Release resources
}

메소드가 예외 또는 정규 리턴 명령문으로 종료 된 방법에 관계없이 자원을 해제합니다.

이것이 좋든 나쁘 든 논쟁의 여지가 있지만 try {} finally {}항상 예외 처리에만 국한되는 것은 아닙니다.

나는 또는이 대답에 다른 언어 프로그래머 Pythonistas의 진노가 (내가 많이 파이썬을 사용하지 않기 때문에 모르는) 호출 할 수 있지만, 제 생각에 대부분의 기능을해야 하지 이 catch블록, 이상적으로 말하기. 이유를 설명하기 위해 80 년대 후반과 90 년대 초에 Turbo C로 작업 할 때해야했던 수동 오류 코드 전파와 이것을 대조해 보겠습니다.

따라서 사용자가로드 할 이미지 파일을 선택하는 것에 대한 응답으로 이미지 또는 이와 유사한 것을로드하는 기능이 있다고 가정 해 봅시다. 이것은 C와 어셈블리로 작성됩니다.

저수준 함수를 생략했지만 오류 처리와 관련한 책임에 따라 색상으로 구분 된 여러 범주의 함수를 식별했음을 알 수 있습니다.

장애 지점 및 복구

이제 내가 "가능한 실패 지점"( throw즉, 실패 ) 및 "오류 복구 및보고"기능 (즉, 실패)이라고 부르는 기능 범주를 작성하는 것은 결코 어려운 일이 아닙니다 catch.

이러한 기능은 항상 메모리를 할당하는데 실패와 같은 외부 고장으로 실행할 수있는 기능은, 단지 반환 할 수 있기 때문에 예외 처리가 가능했던 제대로하기 전에 작성하는 사소한 있었다 NULL또는 0또는 -1또는이 효과에 글로벌 오류 코드 또는 뭔가를 설정합니다. 그리고 오류 복구 및보고는 호출 스택에서 장애를 복구 및보고하는 것이 합리적 수준으로 진행되면 오류 코드 및 / 또는 메시지를 가져 와서 사용자에게보고하기 때문에 항상 쉬웠습니다. 그리고 자연스럽게이 계층의 잎에서 함수는 미래에 어떻게 변경되는지에 관계없이 절대 실패하지 않을 수 있습니다 ( Convert Pixel)는 (적어도 오류 처리와 관련하여) 올바르게 작성하는 것이 간단합니다.

오류 전파

그러나 인적 오류가 발생하기 쉬운 지루한 기능은 오류 전파자 인데, 이는 직접 실패하지는 않았지만 계층 구조의 깊숙한 곳에서 실패 할 수있는 기능이라고 하는 오류 전파자 입니다. 이 시점에서 Allocate Scanline오류를 처리 한 malloc다음 오류를로 되돌려 보내야 할 수도 있습니다 Convert Scanlines. 그런 다음 Convert Scanlines해당 오류를 확인한 후 오류를보고 Decompress Image한 Decompress Image->Parse Image,, 및 Parse Image->Load Image, Load Image사용자 엔드 명령으로 전달해야합니다. .

오류를 제대로 처리 할 때 전체 기능 계층에 대한 오류를 확인하고 전달하는 데 오류 전파자가 하나만 걸리기 때문에 많은 사람이 실수를 저지르는 곳입니다.

또한 오류 코드가 함수에 의해 반환되면 코드베이스의 90 %에서 성공 에 대한 관심 값을 반환하는 기능이 거의 손실 되므로 많은 함수가 오류 코드 를 반환하기 위해 반환 값을 예약해야하기 때문에 실패 .

인적 오류 감소 : 전역 오류 코드

그렇다면 어떻게 인간의 실수 가능성을 줄일 수 있습니까? 여기서는 일부 C 프로그래머의 분노를 불러 일으킬 수도 있지만 OpenGL과 같은 전역 오류 코드 를 사용하는 것이 내 의견을 즉시 개선하는 것 입니다 glGetError. 이것은 적어도 함수가 성공에 대한 의미있는 관심 값을 리턴하도록 해방합니다. 오류 코드가 스레드에 지역화 된 경우이 스레드 안전하고 효율적으로 만드는 방법이 있습니다.

함수가 오류를 일으킬 수있는 경우도 있지만 이전 오류를 발견 한 결과로 조기에 반환되기 전에 조금 더 오래가는 것이 상대적으로 무해합니다. 이를 통해 모든 단일 함수에서 수행되는 함수 호출의 90 %에 대해 오류를 확인할 필요없이 이러한 일이 발생할 수 있으므로 여전히 세심한 오류없이 적절한 오류 처리가 가능합니다.

휴먼 오류 줄이기 : 예외 처리

그러나 위의 솔루션은 수동 if error happened, return error유형의 코드 줄 수를 줄인 경우에도 수동 오류 전파의 제어 흐름 측면을 처리하기 위해 여전히 많은 기능이 필요 합니다. 오류를 검사하고 거의 모든 단일 오류 전파 기능을 반환하는 장소가 하나 이상 있어야하기 때문에 완전히 제거하지는 않습니다. 따라서 예외 처리가 사진을 찍어 하루를 저장하는 경우입니다.

그러나 여기서 예외 처리의 가치는 수동 오류 전파의 제어 흐름 측면을 처리 할 필요가 없다는 것입니다. 그것은 그 가치가 catch코드베이스 전체에 보트로드를 작성하지 않아도되는 능력과 관련이 있음을 의미합니다 . 위의 다이어그램에서 catch블록 을 가져야하는 유일한 위치 Load Image User Command는 오류가보고 된 곳입니다. catch그렇지 않으면 오류 코드 처리만큼 지루하고 오류가 발생하기 쉽기 때문에 다른 어떤 것도 이상적으로해야 할 일은 없습니다 .

따라서 나에게 묻는다면, 우아한 방식으로 예외 처리의 이점을 실제로 얻을 수있는 코드베이스가 있다면 최소catch 블록 수를 가져야합니다 (최소한 나는 0을 의미하지 않지만 모든 고유 한 최고에 대해 하나 더 중앙 명령 시스템을 통해 모든 고급 사용자 작업이 호출되는 경우 실패 할 수있는 최종 사용자 작업, 그리고 아마도 더 적은 작업).

자원 정리

그러나 예외 처리는 정상적인 실행 흐름과 별 개인 예외 경로에서 오류 전파의 제어 흐름 측면을 수동으로 처리하지 않아도됩니다. 종종 오류 전파자 역할을하는 기능은 EH를 사용하여 자동으로 수행하더라도 파괴해야 할 리소스를 여전히 확보 할 수 있습니다. 예를 들어, 그러한 함수는 무엇이든 상관없이 함수에서 복귀하기 전에 닫아야하는 임시 파일을 열거 나, 뮤텍스를 잠그면 잠금 해제해야합니다.

이를 위해 모든 종류의 언어에서 많은 프로그래머의 분노를 불러 일으킬 수 있지만 C ++ 접근 방식이 이상적이라고 생각합니다. 이 언어 는 객체가 범위를 벗어난 순간 결정적 방식으로 호출되는 소멸자 를 소개 합니다. 이 때문에 소멸자가있는 범위가 지정된 뮤텍스 객체를 통해 뮤텍스를 잠그는 C ++ 코드는 수동으로 잠금을 해제 할 필요가 없습니다. 발생). 따라서 잘 작성된 C ++ 코드가 로컬 리소스 정리를 처리 할 필요가 없습니다.

소멸자가없는 언어에서는 finally로컬 리소스를 수동으로 정리하기 위해 블록을 사용해야 할 수도 있습니다 . 즉, 여전히 수동 에러 전파와 코드가 쓰레기를 가지고 뛰는 말했다 제공 당신이없는 catch모든 괴물이 여기 저기 예외.

외부 부작용 반전

이다 해결하기 가장 어려운 개념 문제. 오류 전파이든 오류 지점이든 외부 부작용을 유발하는 기능이있는 경우 해당 기능을 롤백하거나 "실행 취소"하여 시스템이 작동이 발생하지 않은 것처럼 " half-valid "상태이며 작업이 중간에 성공했습니다. 나는 불변성과 지속적인 데이터 구조를 중심으로하는 기능적 언어와 같이 외부 부작용을 일으키는 대부분의 기능의 필요성을 간단히 줄여주는 언어를 제외하고는이 개념적인 문제를 훨씬 쉽게 해줄 언어가 없다.

finally가변성과 부작용을 중심으로하는 언어에서 문제에 대한 가장 우아한 해결책은 다음과 같습니다. 종종 이러한 유형의 논리는 특정 기능에 매우 구체적이고 "자원 정리"개념에 잘 맞지 않기 때문입니다. ". 그리고이 finally경우 자유롭게 사용하여 catch블록 이 필요한지 여부에 관계없이 함수가 지원하는 언어의 부작용을 되돌릴 수 있도록하는 것이 좋습니다 (다시 물어 보면 잘 작성된 코드의 최소 개수는 catch블록과 모든 catch블록은 위의 다이어그램과 같이 가장 의미가있는 곳에 있어야합니다 Load Image User Command.

꿈의 언어

그러나 IMO finally는 부작용 반전에 이상적이지만 그다지 좋지 않습니다. boolean조기 종료의 경우 (예외 예외에서 또는 기타로) 부작용을 효과적으로 롤백하려면 하나의 변수 를 도입해야합니다 .

bool finished = false;
try
{
    // Cause external side effects.
    ...

    // Indicate that all the external side effects were
    // made successfully.
    finished = true; 
}
finally
{
    // If the function prematurely exited before finishing
    // causing all of its side effects, whether as a result of
    // an early 'return' statement or an exception, undo the
    // side effects.
    if (!finished)
    {
        // Undo side effects.
        ...
    }
}

언어를 디자인 할 수 있다면이 문제를 해결하는 꿈의 방법은 위 코드를 자동화하는 것과 같습니다.

transaction
{
    // Cause external side effects.
    ...
}
rollback
{
    // This block is only executed if the above 'transaction'
    // block didn't reach its end, either as a result of a premature
    // 'return' or an exception.

    // Undo side effects.
    ...
}

... 소멸자는 그래서 우리는 필요하고, 지역 자원의 정리를 자동화하는 transaction, rollback그리고 catch(나는 아직도 추가 할 수 있지만 finally말을 위해 자신을 정리하지 않는 C 자원과 작업). 그러나 finally로모그래퍼 boolean변수 내 꿈의 언어를 결여 지금까지 발견 한 것을이 간단하기에 가장 가까운 것입니다. 내가 찾은 두 번째로 가장 간단한 솔루션은 C ++ 및 D와 같은 언어의 스코프 가드 이지만 "리소스 정리"및 "부작용 반전"이라는 개념을 흐리게하므로 스코프 가드는 개념적으로 항상 다소 어색하다는 것을 알았습니다. 제 생각에는 그것들은 다른 방식으로 다루어 질 매우 독특한 아이디어입니다.

언어에 대한 나의 작은 파이프 꿈은 불변성과 영구적 인 데이터 구조를 중심으로 크게 회전하여 함수가 발생하더라도 대량의 데이터 구조를 전체적으로 딥 카피 할 필요가없는 효율적인 함수를 작성하는 것이 더 쉽지는 않지만 필요하지는 않습니다. 부작용이 없습니다.

결론

어쨌든, 내 멍청이를 제쳐두고, try/finally파이썬에는 소멸자와 동등한 C ++이 없다는 것을 고려할 때 소켓을 닫는 코드가 훌륭하고 훌륭하다고 생각하며 개인적으로 부작용을 되돌려 야 할 장소에 자유롭게 사용해야한다고 생각합니다. catch가장 적합한 곳으로 가야 할 곳의 수를 최소화하십시오 .

필수 사항이 아니더라도 오류 / 예외를 파악하고 깔끔하게 처리하는 것이 좋습니다.

내가 말하는 이유는 모든 개발자가 자신의 응용 프로그램의 동작을 알고 해결해야한다고 믿기 때문입니다. try-finally 블록이 try-catch-finally 블록을 대체하는 상황은 없습니다.

간단한 예를 들겠습니다. 예외를 포착하지 않고 서버에 파일을 업로드하기위한 코드를 작성했다고 가정합니다. 어떤 이유로 든 업로드에 실패하면 클라이언트는 무엇이 잘못되었는지 알 수 없습니다. 그러나 예외를 발견 한 경우 무엇이 잘못되었고 사용자가이를 해결하는 방법을 설명하는 깔끔한 오류 메시지를 표시 할 수 있습니다.

황금률 : 추측에는 시간이 걸리기 때문에 항상 예외를 잡아라