무언가를 '시도'하고 예외를 포착하거나 예외를 피하는 것이 가능한지 테스트하는 것이 더 낫습니까?

if무언가가 유효한지 테스트해야합니까, 아니면 try예외를 잡아야합니까?

• 한 가지 방법이 선호된다는 확실한 문서가 있습니까?
• 한 가지 방법은 더 파이썬 입니까?

예를 들어,

if len(my_list) >= 4:
    x = my_list[3]
else:
    x = 'NO_ABC'

또는:

try:
    x = my_list[3]
except IndexError:
    x = 'NO_ABC'

몇 가지 생각 ...
PEP 20 은 말합니다 :

오류가 자동으로 전달되지 않아야합니다.
명시 적으로 침묵하지 않는 한.

try대신에를 사용하는 것이 if자동으로 전달되는 오류로 해석되어야합니까? 그렇다면, 이런 식으로 그것을 사용하여 명시 적으로 침묵 시키는가?

나는 당신 이 한 가지 일만 할 수있는 상황에 대해서는 언급 하지 않습니다 . 예를 들면 다음과 같습니다.

try:
    import foo
except ImportError:
    import baz

당신은 좋아한다 try/except를 통해 if/else그 결과의 경우

• 추가 조회를 방지하여 속도 향상
• 더 깔끔한 코드

종종 이들은 서로 밀접한 관계가 있습니다.

속도 향상

긴 목록에서 요소를 찾으려고 할 경우 :

try:
    x = my_list[index]
except IndexError:
    x = 'NO_ABC'

가 index목록에 있고 IndexError가 발생하지 않는 경우를 제외하고는 try를 사용하는 것이 가장 좋습니다 . 이 방법으로에 의해 추가 조회가 필요하지 않습니다 if index < len(my_list).

파이썬은 예외 사용을 권장합니다. 예외 처리 는 Dive Into Python 의 문구입니다 . 귀하의 예제는 예외를 자동으로 전달 하는 대신 예외를 정상적으로 처리 할뿐만 아니라 예외 를 발견 할 수없는 예외적 인 경우 에만 예외가 발생합니다 (따라서 단어 예외 !).

깔끔한 코드

공식 파이썬 문서는 EAFP : 권한보다 용서를 구하는 것이 더 쉽다고 언급 하고 Rob Knight 는 실수를 피하는 대신 잡는 것이 더 깨끗하고 읽기 쉬운 코드를 만들 수 있다고 지적합니다 . 그의 예는 다음과 같이 말합니다.

더 나빠 (LBYL '도약 전에 봐') :

#check whether int conversion will raise an error
if not isinstance(s, str) or not s.isdigit():
    return None
elif len(s) > 10:    #too many digits for int conversion
    return None
else:
    return int(s)

더 나은 (EAFP : 허가보다 용서를 구하는 것이 더 쉽다) :

try:
    return int(s)
except (TypeError, ValueError, OverflowError): #int conversion failed
    return None

이 특별한 경우에는 완전히 다른 것을 사용해야합니다.

x = myDict.get("ABC", "NO_ABC")

그러나 일반적으로 : 테스트가 자주 실패 할 것으로 예상되는 경우을 사용하십시오 if. 작업을 시도하고 실패한 경우 예외를 포착하는 것과 비교하여 테스트 비용이 비싸면를 사용하십시오 try. 이러한 조건 중 어느 것도 해당되지 않으면 더 쉽게 읽을 수 있습니다.

사용 try및 except직접하기보다는 내부 if가드한다 항상 경쟁 조건의 가능성이있는 경우 수행 할 수. 예를 들어, 디렉토리가 존재하는지 확인하려면 다음을 수행하지 마십시오.

import os, sys
if not os.path.isdir('foo'):
  try:
    os.mkdir('foo')
  except OSError, e
    print e
    sys.exit(1)

다른 스레드 또는 프로세스가 isdir와 사이에 디렉토리를 생성하면 mkdir종료됩니다. 대신 다음을 수행하십시오.

import os, sys, errno
try:
  os.mkdir('foo')
except OSError, e
  if e.errno != errno.EEXIST:
    print e
    sys.exit(1)

'foo'디렉토리를 만들 수없는 경우에만 종료됩니다.

실패하기 전에 어떤 일이 실패하는지 확인하는 것이 사소한 경우에는 그 점을 선호해야합니다. 결국 예외를 구성 (관련된 역 추적 포함)하는 데 시간이 걸립니다.

다음에 대한 예외를 사용해야합니다.

1. 예상치 못한 것들, 또는 ...
2. 하나 이상의 로직 레벨을 뛰어 넘어야하는 것 (예 : break충분하지 않은 곳 ) 또는 ...
3. 미리 예외를 처리 할 대상을 정확히 모르거나
4. 고장에 대해 미리 점검하는 것이 비용이 많이 드는 것 (작업을 시도하는 것에 비해)

예를 들어 첫 번째 예에서 실제로 해야 할 일은 .get()기본값을 제공하기 위해 사용 하는 것입니다.

x = myDict.get('ABC', 'NO_ABC')

다른 게시물에서 언급했듯이 상황에 따라 다릅니다. 데이터의 유효성을 미리 확인하는 대신, 특히 대규모 프로젝트에서 데이터를 사용할 때 try / except를 사용하면 몇 가지 위험이 있습니다.

• try 블록의 코드는 예외가 발생하기 전에 모든 종류의 혼란을 일으킬 수 있습니다. if 문을 사전에 미리 확인하면 이것을 피할 수 있습니다.
• try 블록에서 호출 된 코드가 TypeError 또는 ValueError와 같은 일반적인 예외 유형을 발생시키는 경우 실제로 예상했던 것과 동일한 예외를 catch하지 못할 수도 있습니다. 예외가 제기 될 수있는 라인.

예를 들어,

try:
    x = my_list[index_list[3]]
except IndexError:
    x = 'NO_ABC'

IndexError는 index_list 또는 my_list의 요소를 가져 오려고 할 때 발생했는지에 대해 아무 것도 말하지 않습니다.

if 대신 try를 사용하는 것이 자동으로 전달되는 오류로 해석되어야합니까? 그렇다면, 이런 식으로 사용하여 명시 적으로 침묵시키는 것입니까?

사용 try은 오류가 전달 될 수 있음을 인식하고 있습니다. 이는 오류를 자동으로 전달하는 것과 반대입니다. 사용 except하면 전혀 전달되지 않습니다.

논리가 더 복잡한 try: except:경우에 사용하는 것이 좋습니다 if: else:. 단순한 것이 복잡한 것보다 낫습니다. 복잡한 것이 복잡한 것보다 낫습니다. 허락보다 용서를 구하는 것이 더 쉽습니다.

"자동으로 오류를 전달해서는 안된다"는 경고는 코드에서 사용자가 알고있는 예외를 제기 할 수 있고 설계에서 가능성을 인정하는 경우이지만 예외를 처리하는 방식으로 설계되지 않은 경우입니다. 내 관점에서 볼 때 오류를 명시 적 pass으로 except차단 하는 것은 블록 에서 와 같은 작업을 수행하는 것입니다. 이는 "아무것도하지 않음"이 실제로 특정 상황에서 올바른 오류 처리라는 것을 이해해야합니다. (이것은 잘 작성된 코드에서 주석처럼 느껴질 수있는 몇 번 중 하나입니다.)

그러나 특정 예에서 어느 것도 적절하지 않습니다.

x = myDict.get('ABC', 'NO_ABC')

모든 사람들이 이것을 지적하는 이유는 일반적으로 이해하려는 욕구를 인정하고 더 나은 예를 제시 할 수 없다는 것입니다. 실제로 많은 경우에 동등한 부수적 인 단계가 실제로 존재하기 때문입니다. 문제 해결의 첫 번째 단계.

try/except제어 흐름에 사용할 때마다 다음을 자문하십시오.

1. 언제 try블록이 성공하고 언제 실패 하는지 쉽게 알 수 있습니까?
2. 블록 내부 의 모든 부작용 을 알고 try있습니까?
3. 블록이 예외를 발생 시키는 모든 경우 를 알고 try있습니까?
4. try블록 의 구현이 변경되면 제어 흐름이 여전히 예상대로 작동합니까?

이러한 질문 중 하나 이상에 대한 대답이 '아니요'인 경우 요청해야 할 많은 용서가있을 수 있습니다. 미래의 자기 자신으로부터

예입니다. 최근에 다음과 같은 큰 프로젝트에서 코드를 보았습니다.

try:
    y = foo(x)
except ProgrammingError:
    y = bar(x)

프로그래머와 대화하면서 의도 한 제어 흐름은 다음과 같습니다.

x가 정수이면 y = foo (x)를 수행하십시오.

x가 정수 목록 인 경우 y = bar (x)를 수행하십시오.

이것은 foo데이터베이스 쿼리를 만들었 기 때문에 작동했으며 x정수 이면 쿼리가 성공 하고 ProgrammingErrorif x는 목록이었습니다.

사용 try/except은 잘못된 선택입니다.

1. 예외 이름은 ProgrammingError실제 문제 ( x정수가 아님)를 나타내지 않으므로 진행 상황을 확인하기가 어렵습니다.
2. 는 ProgrammingError데이터베이스 호출, 시간을 낭비하는 동안 발생합니다. foo예외가 발생하기 전에 데이터베이스에 무언가를 쓰거나 다른 시스템의 상태를 변경하는 것이 밝혀지면 정말 끔찍할 것입니다 .
3. 정수 목록 일 ProgrammingError때만 발생 하는지 확실하지 않습니다 x. 예를 들어 foo의 데이터베이스 쿼리에 오타가 있다고 가정하십시오 . 이 또한 발생할 수 있습니다 ProgrammingError. 결과는 정수일 bar(x)때 호출됩니다 x. 이로 인해 암호 예외가 발생하거나 예측할 수없는 결과가 발생할 수 있습니다.
4. 이 try/except블록은의 모든 향후 구현에 요구 사항을 추가합니다 foo. 우리가 변경할 때마다 foo, 우리는 지금이 목록을 처리하는 방법에 대해 생각하고 그것이 발생되었는지 확인해야 ProgrammingError하지, 말, AttributeError전혀 없거나 전혀없는 오류가 발생했습니다.

일반적인 의미를 위해 Python : Exceptions에서 숙어와 안티 이디엄을 읽는 것을 고려할 수 있습니다 .

특별한 경우 다른 사람들이 언급했듯이 다음을 사용해야합니다 dict.get().

get (키 [, 기본값])

키가 사전에 있으면 키의 값을 리턴하고 그렇지 않으면 기본값을 리턴하십시오. 기본값이 지정되지 않은 경우 기본값은 없음으로 설정되므로이 메소드는 KeyError를 발생시키지 않습니다.