예외 처리에 대해 읽고 있습니다. 예외 처리가 무엇인지에 대한 정보를 얻었지만 몇 가지 질문이 있습니다.
답변:
필자가 반드시 읽어야한다고 생각하는 예외에 대한 포괄적 인 가이드는 다음과 같습니다.
예외 및 오류 처리 -C ++ FAQ 또는 C ++ FAQ Lite
일반적으로 프로그램이 외부를 식별 할 수있을 때 예외를 발생시킵니다.실행을 방해하는 문제. 서버에서 데이터를 수신하고 해당 데이터가 유효하지 않은 경우 예외를 발생시킵니다. 디스크 공간이 부족합니까? 예외를 던집니다. 우주 광선이 데이터베이스 쿼리를 방해합니까? 예외를 던집니다. 그러나 자신의 프로그램 내부에서 잘못된 데이터를 얻는 경우 예외를 throw하지 마십시오. 문제가 자신의 잘못된 코드에서 비롯된 경우 ASSERT를 사용하여이를 방지하는 것이 좋습니다. 사용자가 처리 할 수 있기 때문에 프로그램이 처리 할 수없는 문제를 식별하고 사용자에 대해 알리려면 예외 처리가 필요합니다. 그러나 프로그램의 버그는 사용자가 처리 할 수있는 것이 아니므로 프로그램 충돌은 "answer_to_life_and_universe_and_everything의 값이 42가 아닙니다! 절대로 발생하지 않아야합니다 !!!! 11"예외보다 적지 않습니다.
메시지 상자 표시와 같이 유용한 작업을 수행 할 수있는 예외를 포착하십시오. 어떻게 든 사용자 입력을 처리하는 함수 내에서 예외를 포착하는 것을 선호합니다. 예를 들어, 사용자가 "Annihilate all hunams"버튼을 누르고 annihilateAllHunamsClicked () 함수 안에 "I ca n't"라고 말하는 try ... catch 블록이 있습니다. hunamkind의 소멸은 수십, 수십 개의 함수를 호출해야하는 복잡한 작업이지만 한 번의 try ... catch 만 있으면됩니다. 왜냐하면 사용자에게는 하나의 버튼 클릭이라는 원자 적 작업이기 때문입니다. 모든 기능의 예외 검사는 중복되고 추악합니다.
또한 RAII에 익숙해지는 것이 좋습니다. 즉, 초기화 된 모든 데이터가 자동으로 삭제되도록하는 것입니다. 스택에서 가능한 한 많이 초기화하고 힙에서 무언가를 초기화해야 할 때 일종의 스마트 포인터를 사용하면됩니다. 스택에서 초기화 된 모든 것은 예외가 발생하면 자동으로 소멸됩니다. C 스타일 덤 포인터를 사용하는 경우 예외 발생시이를 정리할 사람이 없기 때문에 예외가 throw 될 때 메모리 누수가 발생할 위험이 있습니다 (확실히 C 스타일 포인터를 클래스의 멤버로 사용할 수 있지만 소멸자에서 처리).
fclose좋습니다!). 전체 스택 추적을 제공하지 않습니다.
예외는 다양한 상황에서 유용합니다.
첫째, 전제 조건을 계산하는 비용이 너무 높기 때문에 계산을 수행하고 전제 조건이 충족되지 않은 경우 예외를두고 중단하는 것이 더 좋은 기능이 있습니다. 예를 들어, 특이 행렬을 반전 할 수는 없지만, 특이 행렬을 계산하려면 매우 비용이 많이 드는 행렬식을 계산해야합니다. 어쨌든 함수 내에서 수행해야 할 수도 있으므로 행렬을 반전하고보고 할 때 "시도해보십시오". 예외를 던져서 할 수없는 경우 오류. 이것은 기본적 으로 부정적인 전제 조건 사용 으로 예외 입니다.
그런 다음 코드가 이미 복잡하고 오류 정보를 콜 체인으로 전달하기 어려운 다른 경우가 있습니다. 이것은 부분적으로 C와 C ++가 손상된 데이터 구조 모델을 가지고 있기 때문입니다. 다른 더 나은 방법이 있지만 C ++는이를 지원하지 않습니다 (예 : Haskell에서 모나드 사용). 이 사용은 기본적으로 나는 그것을 옳게하는 것을 귀찮게 할 수 없기 때문에 예외를 던질 것입니다 . 올바른 방법은 아니지만 실용적입니다.
그런 다음 예외의 주요 용도가 있습니다. 메모리 나 디스크 공간과 같은 충분한 리소스와 같은 외부 전제 조건이나 불변성을보고하는 것입니다. 이 경우 일반적으로 프로그램 또는 주요 하위 섹션을 종료하며 예외는 문제에 대한 정보를 전송하는 좋은 방법입니다. C ++ 예외는 프로그램이 계속되는 것을 방해하는 오류를보고하도록 설계되었습니다 .
C ++를 포함하여 대부분의 현대 언어에서 사용되는 예외 처리 모델은 고장난 것으로 알려져 있습니다. 너무 강력합니다. 이론가들은 이제 완전히 개방 된 "무엇이든 던지십시오"및 "아마도 잡을 수없는"모델보다 더 나은 모델을 개발했습니다. 또한 유형 정보를 사용하여 예외를 분류하는 것은 그리 좋은 생각이 아닙니다.
당신이 할 수있는 가장 좋은 방법입니다 그래서 드물게 던져 예외를 할 때 거기에 실제 오류, 그리고 그것을 다루는 다른 방법이 없을 때 와 가능한 한 던져 지점에 가까이 캐치 예외 .
문제가 자신의 잘못된 코드에서 비롯된 경우 ASSERT를 사용하여이를 방지하는 것이 좋습니다. 사용자가 처리 할 수 있기 때문에 프로그램이 처리 할 수없는 문제를 식별하고 사용자에 대해 알리려면 예외 처리가 필요합니다. 그러나 프로그램의 버그는 사용자가 처리 할 수있는 것이 아니므로 프로그램 충돌은
나는 받아 들여진 대답 의이 측면에 동의하지 않는다 . 어설 션은 예외를 던지는 것보다 낫지 않습니다. 예외가 런타임 오류 (또는 "외부 문제")에만 적합하다면 무엇을 std::logic_error위한 것입니까?
논리 오류는 거의 정의상 프로그램이 계속되는 것을 방해하는 종류의 조건입니다. 프로그램이 논리 구조이고 해당 논리 영역 외부에서 조건이 발생하면 어떻게 계속할 수 있습니까? 할 수있는 동안 입력을 모으고 예외를 던지십시오!
선행 기술이없는 것과는 다릅니다. std::vector, 이름은 하나이지만 논리 오류 예외, 즉 std::out_of_range. 표준 라이브러리를 사용하고 표준 예외를 잡을 수있는 최상위 핸들러가없는 경우 ( what () 을 호출 하고 (3)을 종료 하는 경우에만 ) 프로그램이 갑작스럽게 자동 종료됩니다.
assert 매크로는 훨씬 약한 가드입니다. 회복이 없습니다. 즉, 디버그 빌드를 실행하지 않는 경우가 아니면 실행 이 없습니다 . assert 매크로는 계산이 오늘날보다 6 배 더 느린 시대에 속합니다. 논리 오류를 테스트하는 데 어려움을 겪고 있지만 그 테스트가 중요 할 때 사용하지 않는 경우 프로덕션에서 코드에 대해 많은 확신을 갖는 것이 좋습니다!
표준 라이브러리는 논리 오류 예외를 제공하고이를 사용합니다. 이유는 논리 오류가 발생하고 예외적이기 때문입니다. C 기능 어설 션은 예외가 작업을 훨씬 더 잘 처리 할 때 그러한 원시적 (그리고 아마도 쓸모없는) 메커니즘에 의존 할 이유가 없기 때문입니다.
이것에 대한 최고의 읽기
예외 처리는 지난 10 년 반 동안 많은 논의가있었습니다. 그러나 예외를 올바르게 처리하는 방법에 대한 일반적인 합의에도 불구하고 사용에 대한 차이는 계속 존재합니다. 부적절한 예외 처리는 발견하기 쉽고 피하기 쉬우 며 단순한 코드 (및 개발자) 품질 메트릭입니다. 절대적인 규칙이 밀접하거나 과장되어 있다는 것을 알고 있지만 일반적으로 try / catch를 사용해서는 안됩니다.
http://codebetter.com/karlseguin/2010/01/25/don-t-use-try-catch/
try/를 사용하지 마십시오 catch {}.
1. 결과로 예외가 발생할 가능성이 있거나 문제 사이 어딘가에 예외 검사가 코드에 포함됩니다.
2. try-catch 블록은 필요한 경우에만 사용하십시오. 각 try-catch 블록을 사용하면 코드의 최적화를 확실히 줄이는 추가 조건 검사가 추가됩니다.
3. _try_except가 유효한 변수 이름이라고 생각합니다 ....
기본적인 차이점은 다음과 같습니다.
하나는 당신 자신입니다.
예를 들어, 당신은 0 divide error. try catch 1.를 사용 하면 오류가 발생했을 때 도움이됩니다. 또는 당신 if a==0 then..은2.
예외를 잡으려고하지 않으면 더 빠르다고 생각하지 않습니다. 단순히 우회 하면 외부 처리기 error로 threw넘어갑니다.
스스로를 건네는 것은 문제가 더 이상 진행되지 않고 많은 경우에 속도면에서 이점이 있다는 것을 의미하지만 항상 그런 것은 아닙니다.
제안 : 단순하고 논리적으로 자신을 처리하십시오.
많은 C / C ++ 순수 주의자들은 예외를 완전히 권장하지 않습니다. 주요 비판은 다음과 같습니다.
대신 함수를 호출 할 때마다 반환 값 / 오류 코드를 확인하십시오.