나는 "Head First Python" (올해 배우는 언어) 책을 통해 작업하고 있으며 두 가지 코드 기술에 대해 논쟁하는 섹션에 도달했습니다 :
첫 번째 검사와 예외 처리.

다음은 Python 코드 샘플입니다.

# Checking First
for eachLine in open("../../data/sketch.txt"):
    if eachLine.find(":") != -1:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

# Exception handling        
for eachLine in open("../../data/sketch.txt"):
    try:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())
    except:
        pass

첫 번째 예는 .split함수 의 문제를 직접 처리 합니다. 두 번째는 예외 처리기가 처리하도록하고 문제를 무시합니다.

그들은 책에서 먼저 확인하는 대신 예외 처리를 사용한다고 주장합니다. 논점은 예외 코드가 모든 오류를 포착한다는 것입니다. 먼저 검사하면 생각하는 것만 잡을 수 있습니다 (그리고 코너 사례를 놓치게됩니다). 나는 먼저 확인하도록 배웠습니다. 그래서 나의 본능은 그렇게하는 것이었지만 그들의 아이디어는 흥미 롭습니다. 나는 예외 처리를 사용하여 사례를 처리하는 것을 생각하지 못했습니다.

둘 중 어느 것이 일반적으로 더 나은 방법으로 간주됩니까?

.NET에서는 예외를 과도하게 사용하지 않는 것이 일반적입니다. 한 가지 주장은 성능입니다. .NET에서 예외를 발생시키는 것은 계산 비용이 많이 듭니다.

과도한 사용을 피하는 또 다른 이유는 너무 많은 코드를 읽는 것이 매우 어려울 수 있기 때문입니다. Joel Spolsky의 블로그 항목 은 문제를 잘 설명합니다.

논쟁의 핵심은 다음과 같습니다.

추론은 1960 년대 이후로 "고토 (goto 's)"보다 예외가 아니라고 생각한다. 한 코드에서 다른 코드로 갑작스런 점프를하기 때문이다. 실제로 그들은 goto보다 훨씬 나쁩니다.

1. 소스 코드에서 보이지 않습니다 . 예외를 던지거나 던지지 않을 수있는 함수를 포함하여 코드 블록을 살펴보면 어떤 예외가 어디서 발생하는지 확인할 수있는 방법이 없습니다. 이것은 신중한 코드 검사조차도 잠재적 인 버그를 나타내지 않음을 의미합니다.

2. 함수에 대해 가능한 많은 종료점을 작성 합니다. 올바른 코드를 작성하려면 함수를 통해 가능한 모든 코드 경로를 고려해야합니다. 예외를 발생시킬 수있는 함수를 호출하고 그 자리에서 포착하지 못할 때마다 갑자기 종료 된 함수로 인해 깜짝 버그가 발생할 수 있습니다. 생각 해봐

개인적으로 코드에서 계약 한 작업을 수행 할 수없는 경우 예외가 발생합니다. 프로세스 경계 외부의 무언가 (예 : SOAP 호출, 데이터베이스 호출, 파일 IO 또는 시스템 호출)를 처리하려고 할 때 try / catch를 사용하는 경향이 있습니다. 그렇지 않으면 방어 적으로 코딩하려고합니다. 어렵고 빠른 규칙은 아니지만 일반적인 관행입니다.

스콧 Hanselman은 또한 .NET에서 예외에 대한 글을 여기에 . 이 기사에서 그는 예외에 관한 몇 가지 경험 법칙을 설명합니다. 내가 가장 좋아하는?

항상 일어나는 일에 대해 예외를 던져서는 안됩니다. 그렇다면 그들은 "장식품"이 될 것입니다.

특히 파이썬에서는 예외를 잡는 것이 더 나은 방법으로 간주됩니다. LBYL (Look Before You Leap)과 비교할 때 EAFP ( 권한보다 용서를 구하는 것이 더 쉽다) 라고 불리는 경향이 있습니다. 경우에 따라 LBYL이 미묘한 버그 를 발생시키는 경우가 있습니다.

그러나 둘 다 버그를 가릴 수 있으므로 노출 된 except:문장 뿐만 아니라 넓은 문장도 주의해야합니다 .

for eachLine in open("../../data/sketch.txt"):
    try:
        role, lineSpoken = eachLine.split(":",1)
    except ValueError:
        pass
    else:
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

실용적 접근

당신은 방어 적이지만 요점을 가리켜 야합니다. 예외 처리를 작성해야하지만 특정 시점까지 작성해야합니다. 여기가 내가 사는 곳이기 때문에 웹 프로그래밍을 예로 사용하겠습니다.

1. 모든 사용자 입력이 잘못되었다고 가정하고 데이터 유형 확인, 패턴 검사 및 악의적 인 주입 지점에만 방어 적으로 작성하십시오. 방어 적 프로그래밍은 제어 할 수없는 잠재적으로 자주 발생할 수있는 일이어야합니다.
2. 때때로 실패 할 수있는 네트워크 서비스에 대한 예외 처리를 작성하고 사용자 피드백을 위해 정상적으로 처리합니다. 때때로 실패 할 수 있지만 일반적으로 견고하며 프로그램 작동을 유지해야하는 네트워크에 대해서는 예외 프로그래밍을 사용해야합니다.
3. 입력 데이터의 유효성이 검증 된 후 애플리케이션 내에서 방어 적으로 글을 쓰려고하지 마십시오. 시간 낭비이며 앱을 팽창시킵니다. 처리 할 가치가없는 매우 드물 거나 단계 1과 2를보다주의 깊게 살펴 봐야한다는 의미에서 터져 버리십시오 .
4. 네트워크 장치에 의존하지 않는 코어 코드 내에 예외 처리를 작성하지 마십시오. 그렇게하면 프로그래밍이 잘못되고 성능이 저하됩니다. 예를 들어 루프에서 범위를 벗어난 배열에 try-catch를 작성하면 루프를 처음에 올바르게 프로그래밍하지 않았 음을 의미합니다.
5. 위의 절차를 따른 후 한 곳에서 예외를 포착하는 중앙 오류 로깅으로 모든 것을 처리하십시오. 무한대의 모든 경우를 잡을 수는 없으며 예상되는 작업을 처리하는 코드 만 작성하면됩니다. 이것이 마지막 오류로 중앙 오류 처리를 사용하는 이유입니다.
6. TDD는 부풀어 오르지 않은 방식으로 시도하기 때문에 정상적인 작동을 보장합니다.
7. 보너스 포인트는 코드 커버리지 도구 를 사용하는 것입니다. 이스탄불은 테스트하지 않는 위치를 보여주기 때문에 노드에 적합한 도구 입니다.
8. 이 모든 것에 대한 경고 는 개발자 친화적 인 예외 입니다. 예를 들어, 구문을 잘못 사용하고 그 이유를 설명하면 언어가 발생합니다. 따라서 대부분의 코드가 의존하는 유틸리티 라이브러리가 있어야합니다 .

이것은 대규모 팀 시나리오에서의 경험에서 비롯된 것입니다.

유추

항상 ISS 내부에 우주복을 입었다 고 상상해보십시오. 화장실에 가거나 먹기가 어려울 것입니다. 우주 모듈 내부에서 움직이면 부피가 커집니다. 빨 겠어요 코드 안에 여러 시도-캐치를 작성하는 것은 그런 식입니다. 당신은 당신이 말하는 곳을 가지고 있어야합니다. 야, 나는 ISS를 확보했고 내 우주 비행사가 괜찮아서 일어날 수있는 모든 시나리오에 우주복을 입는 것은 실용적이지 않습니다.

이 책의 주요 논점은 코드의 예외 버전이 더 좋다는 것입니다. 자신의 오류 검사를 작성하려고 할 때 간과했을 수도있는 것을 잡아낼 수 있기 때문입니다.

나는이 진술이 출력이 정확한지 신경 쓰지 않는 매우 구체적인 상황에서만 사실이라고 생각합니다.

예외 를 제기 하는 것이 건전하고 안전한 방법이라는 데는 의심의 여지가 없습니다 . 프로그램의 현재 상태에 개발자 (개발자로서)가 처리 할 수 ​​없거나 원하지 않는 것이있을 때마다 그렇게해야합니다.

그러나 귀하의 예는 예외 를 잡는 것에 관한 것 입니다. 예외를 발견하면 간과했을 수도있는 시나리오로부터 자신을 보호 할 수 없습니다 . 정확히 반대의 일을하고 있습니다. 이러한 유형의 예외를 초래할 수있는 시나리오를 간과하지 않았다고 가정하므로 예외를 잡을 수 있다고 확신합니다 (따라서 프로그램이 종료되지 않도록하십시오. 잡히지 않은 예외와 같이).

예외 접근 방식을 사용하면 예외가 표시되면 ValueError줄을 건너 뜁니다. 기존의 비 예외 접근 방식을 사용하여의 반환 값 수를 세고 split2보다 작 으면 한 줄을 건너 뜁니다. 기존의 오류 검사에서 다른 "오류"상황을 잊어 버렸을 수 있으므로 예외 접근 방식이 더 안전하다고 생각 except ValueError하십니까?

프로그램의 특성에 따라 다릅니다.

예를 들어 웹 브라우저 나 비디오 플레이어를 작성하는 경우 입력 문제로 인해 포착되지 않은 예외로 인해 입력이 중단되지 않아야합니다. 종료하는 것보다 원격으로 감지 할 수있는 (엄격하게 말해서, 잘못하더라도) 출력하는 것이 훨씬 좋습니다.

정확성이 중요한 응용 프로그램 (예 : 비즈니스 또는 엔지니어링 소프트웨어)을 작성하는 경우 이는 끔찍한 접근 방식입니다. 발생하는 시나리오를 잊어 버린 경우 ValueError최악의 상황은 알 수없는이 시나리오를 자동으로 무시하고 단순히 줄을 건너 뛰는 것입니다. 이것이 소프트웨어에서 매우 미묘하고 값 비싼 버그가 발생하는 방식입니다.

ValueError이 코드에서 볼 수있는 유일한 방법 split은 두 값 대신 하나의 값만 반환하는 것입니다. 그러나 만약 당신의 print진술이 나중에 ValueError어떤 조건 하에서 일어나는 표현을 사용하기 시작 한다면 어떨까요? 이로 인해 누락 된 :것이 아니라 print실패 하기 때문에 일부 줄을 건너 뛸 수 있습니다. 이것은 내가 이전에 언급 한 미묘한 버그의 예입니다. 아무것도 알지 못하고 일부 줄을 잃어 버립니다.

내 권장 사항은 잘못된 출력을 생성하는 것이 종료하는 것보다 나쁜 코드에서 예외를 잡아내는 것을 피하는 것입니다. 그러한 코드에서 예외를 잡을 수있는 유일한 시간은 진정으로 사소한 표현이있을 때뿐이므로 가능한 각 예외 유형을 유발할 수있는 원인을 쉽게 추론 할 수 있습니다.

예외 사용의 성능 영향과 관련하여 예외가 자주 발생하지 않는 한 (파이썬에서는) 사소합니다.

예외를 사용하여 일상적으로 발생하는 조건을 처리하는 경우 경우에 따라 막대한 성능 비용이 발생할 수 있습니다. 예를 들어, 일부 명령을 원격으로 실행한다고 가정하십시오. 명령 텍스트가 최소한 최소 유효성 검사 (예 : 구문)를 통과하는지 확인할 수 있습니다. 또는 원격 서버가 명령을 구문 분석하고 문제를 발견 한 후에 만 ​​예외가 발생할 때까지 기다릴 수 있습니다. 분명히 전자는 수십 배 더 빠릅니다. 또 다른 간단한 예 : 나누기를 실행 한 다음 ZeroDivisionError 예외를 잡는 것보다 숫자가 0 ~ 10 배 빠른지 확인할 수 있습니다.

이러한 고려 사항은 잘못된 형식의 명령 문자열을 원격 서버로 자주 보내거나 나눗셈에 사용하는 값이 0 인 인수를받는 경우에만 중요합니다.

참고 : except ValueError그냥 대신 사용한다고 가정합니다 except. 다른 사람들이 지적했듯이 책 자체가 몇 페이지에 나와 있듯이 bare를 사용해서는 안됩니다 except.

또 다른 참고 사항 : 적절한 비 예외 접근 방식은에 split대한 검색 대신에 의해 반환되는 값의 수를 계산하는 것입니다 :. 후자는 작업을 반복 split하고 실행 시간을 거의 두 배로 늘리기 때문에 너무 느립니다 .

일반적으로, 명령문이 유효하지 않은 결과를 생성 할 수 있다는 것을 알고 있으면이를 테스트하고 처리하십시오. 예상치 못한 것에 대해서는 예외를 사용하십시오. "예외적 인"것들. 계약상의 의미로 코드를 더 명확하게 만듭니다 (예 : "null이 아니어야 함").

잘 작동하는 것을 사용하십시오.

• 코드 가독성 및 효율성 측면에서 선택한 프로그래밍 언어
• 팀 및 합의 된 코드 규칙 세트

예외 처리와 방어 프로그래밍 모두 동일한 의도를 표현하는 다른 방법입니다.

TBH, try/except정비사 또는 if명세서 확인 을 사용하는 것은 중요하지 않습니다 . EAFP와 LBYL은 대부분의 Python 기준선에서 일반적으로 볼 수 있으며 EAFP는 약간 더 일반적입니다. 때로는 EAFP 가 훨씬 더 읽기 쉽고 관용적이지만이 경우에는 어느 쪽이든 괜찮습니다.

하나...

나는 당신의 현재 참조를 조심스럽게 사용합니다. 코드에 몇 가지 눈부신 문제가 있습니다.

1. 파일 디스크립터가 누출되었습니다. CPython의 최신 버전 ( 특정 Python 인터프리터)은 루프 동안에 만 범위에있는 익명의 객체이기 때문에 실제로 닫습니다 (gc는 루프 후에 핵을 생성합니다). 그러나 다른 통역사들 에게는이 보증이 없습니다 . 디스크립터가 유출 될 수 있습니다. with파이썬에서 파일을 읽을 때 거의 항상 관용구 를 사용하려고합니다 . 예외는 거의 없습니다. 이것은 그들 중 하나가 아닙니다.
2. 포켓몬 예외 처리는 눈살을 찌푸리게한다 그것은 마스크 오류 (예 : 맨손으로 except문이 특정 예외를 캐치하지 않습니다)
3. Nit : 튜플 포장 풀기를 위해 parens가 필요하지 않습니다. 그냥 할 수 있습니다role, lineSpoken = eachLine.split(":",1)

Ivc는 이것과 EAFP에 대한 좋은 대답을 가지고 있지만 설명자를 유출합니다.

LBYL 버전은 반드시 EAFP 버전만큼 성능이 높을 필요는 없으므로 예외를 던지는 것이 "성능 측면에서 비싸다"는 말은 사실상 거짓입니다. 처리하는 문자열 유형에 따라 다릅니다.

In [33]: def lbyl(lines):
    ...:     for line in lines:
    ...:         if line.find(":") != -1:
    ...:             # Nuke the parens, do tuple unpacking like an idiomatic Python dev.
    ...:             role, lineSpoken = line.split(":",1)
    ...:             # no print, since output is obnoxiously long with %timeit
    ...:

In [34]: def eafp(lines):
    ...:     for line in lines:
    ...:         try:
    ...:             # Nuke the parens, do tuple unpacking like an idiomatic Python dev.
    ...:             role, lineSpoken = eachLine.split(":",1)
    ...:             # no print, since output is obnoxiously long with %timeit
    ...:         except:
    ...:             pass
    ...:

In [35]: lines = ["abc:def", "onetwothree", "xyz:hij"]

In [36]: %timeit lbyl(lines)
100000 loops, best of 3: 1.96 µs per loop

In [37]: %timeit eafp(lines)
100000 loops, best of 3: 4.02 µs per loop

In [38]: lines = ["a"*100000 + ":" + "b", "onetwothree", "abconetwothree"*100]

In [39]: %timeit lbyl(lines)
10000 loops, best of 3: 119 µs per loop

In [40]: %timeit eafp(lines)
100000 loops, best of 3: 4.2 µs per loop

기본적으로 예외 처리 는 OOP 언어에 더 적합해야합니다.

두 번째 요점은 eachLine.find모든 라인에 대해 실행할 필요 가 없기 때문에 성능 입니다.

방어 적 프로그래밍이 성능을 저하 시킨다고 생각합니다. 또한 처리하려는 예외 만 포착해야하며 런타임에 처리 방법을 모르는 예외를 처리하도록하십시오.