sourcecode

Python에서 try-except-else를 사용하는 것이 좋은 방법인가요?

copyscript 2022. 10. 7. 21:51
반응형

Python에서 try-except-else를 사용하는 것이 좋은 방법인가요?

Python에서는 가끔 블록이 보입니다.

try:
   try_this(whatever)
except SomeException as exception:
   #Handle exception
else:
   return something

try-except-else가 존재하는 이유는 무엇입니까?

흐름 제어를 위해 예외를 사용하기 때문에 저는 그런 종류의 프로그래밍을 좋아하지 않습니다.하지만, 만약 그것이 언어에 포함된다면, 분명 그럴 만한 이유가 있을 거예요, 그렇죠?

예외는 오류가 아니며 예외 조건(예를 들어 디스크에 파일을 쓰려고 하고 공간이 없거나 권한이 없는 경우)에만 사용해야 하며 흐름 제어에는 사용하지 않아야 합니다.

일반적으로 다음과 같이 예외를 처리합니다.

something = some_default_value
try:
    something = try_this(whatever)
except SomeException as exception:
    #Handle exception
finally:
    return something

또는 예외가 발생했을 때 아무것도 반환하지 않을 경우 다음 절차를 수행합니다.

try:
    something = try_this(whatever)
    return something
except SomeException as exception:
    #Handle exception

"무지에서 비롯된 것인지 모르겠지만, 흐름 제어를 위해 예외를 사용하는 그런 종류의 프로그래밍은 좋아하지 않습니다.

Python 세계에서는 흐름 제어에 예외를 사용하는 것이 일반적이며 일반적입니다.

심지어 Python 코어 개발자들도 흐름 제어에 예외를 사용하고 있으며 이러한 스타일은 언어에 많이 기반되어 있습니다(즉, 반복자 프로토콜은 정지 반복을 사용하여 루프 종료를 신호로 합니다).

또한 try-except 스타일은 일부 "Look-before-you-leap" 구조에 내재된 레이스 조건을 방지하기 위해 사용됩니다.예를 들어 os.path.exists테스트하면 정보를 사용할 때까지 최신이 아닐 수 있습니다.마찬가지로 큐.full은 오래된 정보를 반환합니다.이러한 경우 try-except-else 스타일은 보다 신뢰할 수 있는 코드를 생성합니다.

예외는 오류가 아니라 예외적인 경우에만 사용해야 한다고 생각합니다.

몇몇 다른 언어에서는, 그 규칙이 그들의 도서관에 반영되어 있는 그들의 문화적 규범을 반영한다.또, 「규칙」은, 이러한 언어의 퍼포먼스 고려 사항에 근거하고 있습니다.

Python의 문화적 규범은 다소 다르다.대부분의 경우 제어 흐름에 예외를 사용해야 합니다.또한 Python에서 예외를 사용해도 컴파일된 일부 언어에서처럼 주변 코드와 호출 코드가 느려지지 않습니다(즉, CPython은 예외를 실제로 사용하든 사용하지 않든 모든 단계에서 예외 확인을 위한 코드를 이미 구현하고 있습니다).

즉, "예외는 예외"라는 것은 일부 다른 언어에서는 의미가 있지만 Python에서는 의미가 없다는 것을 이해하는 것입니다.

하지만 언어 자체에 포함되어 있다면 그럴 만한 이유가 있겠죠?

예외는 레이스 조건을 회피하는 데 도움이 될 뿐만 아니라 에러 처리의 외부 루프를 끌어내는 데도 매우 편리합니다.이것은 자동 루프 불변 코드 모션이 없는 경향이 있는 인터프리터 언어에서 필요한 최적화입니다.

또한 예외는 문제를 처리하는 기능이 문제가 발생한 곳에서 멀리 떨어져 있는 일반적인 상황에서 코드를 상당히 단순화할 수 있습니다.예를 들어 비즈니스 로직의 최상위 사용자 인터페이스 코드 호출 코드가 있는 것이 일반적이며, 이는 하위 루틴을 호출합니다.하위 수준의 루틴에서 발생하는 상황(데이터베이스 액세스의 고유 키에 대한 중복 레코드 등)은 최상위 코드로만 처리할 수 있습니다(예: 기존 키와 충돌하지 않는 새 키를 사용자에게 요청).이런 종류의 제어 흐름에 예외를 사용하면 미드레벨 루틴은 문제를 완전히 무시하고 흐름 제어의 측면에서 적절히 분리할 수 있습니다.

여기에 예외의 필요성에 대한 멋진 블로그 게시물이 있다.

또한 다음 Stack Overflow 답변도 참조하십시오.예외는 예외적인 오류에 대한 것입니까?

"try-except-else가 존재하는 이유는 무엇입니까?"

다른 조항 자체가 재미있다예외는 없지만 최종 종료 전에 실행됩니다.그것이 그것의 주된 목적이다.

else-clause를 사용하지 않으면 종료 전에 추가 코드를 실행할 수 있는 유일한 옵션은 코드를 트라이-clause에 추가하는 서투른 방법일 것입니다.이는 테스트 블록에 의해 보호되지 않는 코드의 예외를 발생시킬 위험이 있기 때문에 서툴다.

최종화 전에 보호되지 않은 추가 코드를 실행하는 사용 사례는 자주 발생하지 않습니다.따라서 공개된 코드에서 많은 예를 볼 수 있을 것으로 기대하지 마십시오.그것은 다소 희귀하다.

else-clause의 또 다른 사용 사례는 예외가 발생하지 않을 때와 예외가 처리될 때 발생하지 않는 작업을 수행하는 것입니다.예를 들어 다음과 같습니다.

recip = float('Inf')
try:
    recip = 1 / f(x)
except ZeroDivisionError:
    logging.info('Infinite result')
else:
    logging.info('Finite result')

또 다른 예는 가장 짧은 러너에서 발생합니다.

try:
    tests_run += 1
    run_testcase(case)
except Exception:
    tests_failed += 1
    logging.exception('Failing test case: %r', case)
    print('F', end='')
else:
    logging.info('Successful test case: %r', case)
    print('.', end='')

마지막으로, 테스트 블록에서 else-clause의 가장 일반적인 용도는 약간의 미화(예외적인 결과와 예외적이지 않은 결과를 동일한 들여쓰기 수준에서 정렬)입니다.이 사용은 항상 옵션이며 반드시 필요한 것은 아닙니다.

try-except-else가 존재하는 이유는 무엇입니까?

A try블록을 사용하면 예상되는 오류를 처리할 수 있습니다.except블록은 처리할 준비가 된 예외만 포착해야 합니다.예기치 않은 오류를 처리하면 코드가 잘못된 작업을 수행하여 버그를 숨길 수 있습니다.

else없는 이 실행되며, 이됩니다.try블록, 예기치 않은 오류가 발생하지 않도록 합니다.또, 예기치 않은 에러를 검출하면, 버그를 숨길 수 있습니다.

예를 들어 다음과 같습니다.

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
else:
    return something

except" 에는 "try, except"라는 두 구가 .else ★★★★★★★★★★★★★★★★★」finally그래서 사실...try-except-else-finally.

else는 예외 합니다.try블록입니다.아래의 보다 복잡한 코드를 간단하게 할 수 있습니다.

no_error = None
try:
    try_this(whatever)
    no_error = True
except SomeException as the_exception:
    handle(the_exception)
if no_error:
    return something

''를 else대체 수단(버그가 발생할 수 있음)으로 코드 행을 줄이고 읽기 쉽고 유지보수가 용이하며 버그가 적은 코드 베이스를 얻을 수 있음을 알 수 있습니다.

finally

finally는 리턴 스테이트먼트를 사용하여 다른 회선을 평가하더라도 어떤 경우에도 실행됩니다.

유사 코드로 분해됨

가능한 한 작은 형태로 모든 기능을 설명하여 설명하면 도움이 될 수 있습니다.이 구문적으로는 올바르지만 이름이 정의되지 않는 한 실행할 수 없는 의사 코드가 함수에 있다고 가정합니다.

예를 들어 다음과 같습니다.

try:
    try_this(whatever)
except SomeException as the_exception:
    handle_SomeException(the_exception)
    # Handle a instance of SomeException or a subclass of it.
except Exception as the_exception:
    generic_handle(the_exception)
    # Handle any other exception that inherits from Exception
    # - doesn't include GeneratorExit, KeyboardInterrupt, SystemExit
    # Avoid bare `except:`
else: # there was no exception whatsoever
    return something()
    # if no exception, the "something()" gets evaluated,
    # but the return will not be executed due to the return in the
    # finally block below.
finally:
    # this block will execute no matter what, even if no exception,
    # after "something" is eval'd but before that value is returned
    # but even if there is an exception.
    # a return here will hijack the return functionality. e.g.:
    return True # hijacks the return in the else clause above

이 코드를 포함시킬 수 있는 것은 사실입니다.elsetry예외 없이 실행할 수 있는 블록입니다만, 만약 그 코드 자체가 우리가 잡는 종류의 예외를 발생시킨다면 어떻게 될까요?에 the the the the the the leaving try막다

.try블록은 코드가 실패하면 크게 실패한다는 원칙 하에 예상치 못한 예외를 포착하지 않도록 합니다.이것은 베스트 프랙티스입니다.

예외는 오류가 아닌 것으로 알고 있습니다.

Python에서는 대부분의 예외는 오류입니다.

pydoc을 사용하면 예외 계층을 볼 수 있습니다.예를 들어 Python 2의 경우:

$ python -m pydoc exceptions

또는 Python 3:

$ python -m pydoc builtins

우리에게 위계질서를 줄 거야우리는 대부분의 종류의 사람들이Exception그 중 일부를 Python 종료와 같은 입니다.forsloops(루프)StopIteration파이썬 3 의 음 음 음 음 음 음 python python python python python python python python 。

BaseException
    Exception
        ArithmeticError
            FloatingPointError
            OverflowError
            ZeroDivisionError
        AssertionError
        AttributeError
        BufferError
        EOFError
        ImportError
            ModuleNotFoundError
        LookupError
            IndexError
            KeyError
        MemoryError
        NameError
            UnboundLocalError
        OSError
            BlockingIOError
            ChildProcessError
            ConnectionError
                BrokenPipeError
                ConnectionAbortedError
                ConnectionRefusedError
                ConnectionResetError
            FileExistsError
            FileNotFoundError
            InterruptedError
            IsADirectoryError
            NotADirectoryError
            PermissionError
            ProcessLookupError
            TimeoutError
        ReferenceError
        RuntimeError
            NotImplementedError
            RecursionError
        StopAsyncIteration
        StopIteration
        SyntaxError
            IndentationError
                TabError
        SystemError
        TypeError
        ValueError
            UnicodeError
                UnicodeDecodeError
                UnicodeEncodeError
                UnicodeTranslateError
        Warning
            BytesWarning
            DeprecationWarning
            FutureWarning
            ImportWarning
            PendingDeprecationWarning
            ResourceWarning
            RuntimeWarning
            SyntaxWarning
            UnicodeWarning
            UserWarning
    GeneratorExit
    KeyboardInterrupt
    SystemExit

코멘트 작성자는 다음과 같이 질문했습니다.

외부 API에 ping을 실행하는 메서드가 있고 API 래퍼 외부의 클래스에서 예외를 처리하고 싶다고 하면 except 절 아래의 메서드에서 e를 반환하기만 하면 됩니까? e는 예외 객체입니다.

그냥 .raise이치노

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
    raise

또는 Python 3에서는 새로운 예외를 발생시켜 예외 체인을 포함한 역추적을 유지할 수 있습니다.

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
    raise DifferentException from the_exception

는 여기서 나의 대답을 자세히 한다.

Python은 예외가 예외적인 경우에만 사용되어야 한다는 생각에 동의하지 않습니다. 사실 관용구는 '허가가 아닌 용서를 구한다'입니다.즉, 예외를 흐름 제어의 일상적인 부분으로 사용하는 것은 완벽하게 허용되며 실제로 권장됩니다.

이것은 일반적으로 좋은 것입니다.이렇게 작업하면 몇 가지 문제를 회피할 수 있고(명백한 예로서 인종 조건은 회피되는 경우가 많다), 코드를 조금 더 읽기 쉽게 만드는 경향이 있기 때문입니다.

처리할 필요가 있는 사용자 입력을 받고 있지만 이미 처리되어 있는 기본값이 있다고 가정해 보십시오.try: ... except: ... else: ...을 사용법

try:
   raw_value = int(input())
except ValueError:
   value = some_processed_value
else: # no error occured
   value = process_value(raw_value)

다른 언어의 경우와 비교해 보십시오.

raw_value = input()
if valid_number(raw_value):
    value = process_value(int(raw_value))
else:
    value = some_processed_value

이점에 주의해 주세요.값이 유효한지 확인하고 별도로 해석할 필요가 없습니다.이러한 작업은 1회 실행됩니다.또한 코드는 보다 논리적인 진행을 따르며, 주 코드 경로가 먼저이고, '작동하지 않으면 이렇게 하십시오'가 그 뒤를 잇습니다.

이 예는 당연히 약간 조작된 것이지만, 이 구조에 대한 사례가 있다는 것을 보여준다.

다음 예에서는 try-except-else-finally의 모든 것을 설명합니다.

for i in range(3):
    try:
        y = 1 / i
    except ZeroDivisionError:
        print(f"\ti = {i}")
        print("\tError report: ZeroDivisionError")
    else:
        print(f"\ti = {i}")
        print(f"\tNo error report and y equals {y}")
    finally:
        print("Try block is run.")

구현 및 이용 가능:

    i = 0
    Error report: ZeroDivisionError
Try block is run.
    i = 1
    No error report and y equals 1.0
Try block is run.
    i = 2
    No error report and y equals 0.5
Try block is run.

python에서 try-except-else를 사용하는 것이 좋은 방법인가요?

이에 대한 답은 컨텍스트에 의존한다는 것입니다.이렇게 하면:

d = dict()
try:
    item = d['item']
except KeyError:
    item = 'default'

Python은 Python이라고 합니다.은 에 되어 있습니다.dict.get★★★★

item = d.get('item', 'default')

try/except블록은 원자적인 방법으로 한 줄에서 효율적으로 실행할 수 있는 훨씬 더 시각적으로 혼란스럽고 장황한 글쓰기 방법입니다.을 사용하다

그렇다고 해서 예외 처리를 모두 피해야 하는 것은 아닙니다.경우에 따라서는 경기 조건을 피하는 것이 좋다.파일이 존재하는지 확인하지 말고 파일을 열어보고 적절한 IOError를 포착합니다.단순성과 가독성을 위해 이를 캡슐화하거나 apropos로 인수해 보십시오.

Python의 Zen을 읽고 긴장 상태에 있는 원칙이 있음을 이해하고, 그 중 하나에 너무 많이 의존하는 독단을 경계하십시오.

마지막 블록을 사용하는 것은 다른 블록을 사용하는 것과 동일하지 않으므로 주의해야 합니다.마지막 블록은 시행 결과에 관계없이 실행됩니다(제외).

In [10]: dict_ = {"a": 1}

In [11]: try:
   ....:     dict_["b"]
   ....: except KeyError:
   ....:     pass
   ....: finally:
   ....:     print "something"
   ....:     
something

모두가 알고 있듯이 else 블록을 사용하면 코드를 더 쉽게 읽을 수 있으며 예외가 발생하지 않을 때만 실행됩니다.

In [14]: try:
             dict_["b"]
         except KeyError:
             pass
         else:
             print "something"
   ....:

아무도 이런 의견을 올리지 않았다고 해서

else을 참조해 주세요.try/excepts 대부분의 때문이다.

「」와 달리try,except , , , , 입니다.finally의 " " "else절은 자가 해석되지 않고 읽기 어렵습니다.자주 사용되지 않기 때문에 코드를 읽는 사람들은 무슨 일이 일어나고 있는지 알기 위해 문서를 다시 확인해야 합니다.

은, 제가 했기 try/except/else그 때문에 wtf의 순간이 발생하여 구글링을 하게 되었습니다.)

따라서 OP 예시와 같은 코드를 볼 수 있습니다.

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
else:
    # do some more processing in non-exception case
    return something

나는 에 대해 반박하는 것을 선호한다.

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
    return  # <1>
# do some more processing in non-exception case  <2>
return something
  • <1> 명시적 반환, 예외적인 경우 작업이 완료되었음을 명확히 나타냅니다.

  • 으로서 <2>에, <2>의 코드입니다else블록이 한 레벨씩 전용됩니다.

이 메시지가 표시될 때마다:

try:
    y = 1 / x
except ZeroDivisionError:
    pass
else:
    return y

또는 이것까지:

try:
    return 1 / x
except ZeroDivisionError:
    return None

대신 다음 사항을 고려하십시오.

import contextlib
with contextlib.suppress(ZeroDivisionError):
    return 1 / x

다음은 파이썬에서 try-except-else-finally 블록을 이해하는 방법에 대한 간단한 스니펫입니다.

def div(a, b):
    try:
        a/b
    except ZeroDivisionError:
        print("Zero Division Error detected")
    else:
        print("No Zero Division Error")
    finally:
        print("Finally the division of %d/%d is done" % (a, b))

div 1/1을 사용해 보겠습니다.

div(1, 1)
No Zero Division Error
Finally the division of 1/1 is done

div 1/0을 사용해 봅시다.

div(1, 0)
Zero Division Error detected
Finally the division of 1/0 is done

나는 이 질문에 조금 다른 각도로 대답하려고 한다.

OP의 질문은 2개였고, 3번째 질문도 추가했습니다.

  1. try-except-else가 존재하는 이유는 무엇입니까?
  2. try-except-else 패턴 또는 일반적으로 Python은 흐름 제어에 대한 예외 사용을 권장합니까?
  3. 예외는 언제 사용할까요?

질문 1: Try-except-else가 존재하는 이유는 무엇입니까?

그것은 전술적인 관점에서 대답할 수 있다. 그럴 만한 가 있다try...except...존재하게 됩니다.서 새로 은 「」입니다.else...은 그 요약됩니다.

  • the에서 예외가 하지 않은 경우뿐입니다.이것은, 에 예외가 발생하지 않은 경우 뿐입니다.try...

  • 코드 of itの block block block,블록을 합니다.try... 내에서 할 수 있는 모든 합니다).else...

  • 은 " " " 전에 됩니다.final...최종화

      db = open(...)
      try:
          db.insert(something)
      except Exception:
          db.rollback()
          logging.exception('Failing: %s, db is ROLLED BACK', something)
      else:
          db.commit()
          logging.info(
              'Successful: %d',  # <-- For the sake of demonstration,
                                 # there is a typo %d here to trigger an exception.
                                 # If you move this section into the try... block,
                                 # the flow would unnecessarily go to the rollback path.
              something)
      finally:
          db.close()
    

    에서는 이 줄을 의의음음음음음음음음음음음음음음 the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the the 로 이동할.finally...블록 안쪽으로 옮기면 안 돼요try... 「」의 인 예외에 어느쪽인가로 설정되어 있습니다.else...

질문 2: Python은 흐름 제어에 예외를 사용하는 것을 권장합니까?

저는 그 주장을 뒷받침할 공식 문서를 찾지 못했습니다.(반대하는 독자에게 : 찾은 증거에 대한 링크와 함께 코멘트를 남겨주세요.제가 발견한 유일한 관련 문단은 EAFP 용어입니다.

EAFP

허락보다 용서를 구하는 게 더 쉽죠이 일반적인 Python 코딩 스타일은 유효한 키 또는 속성이 존재한다고 가정하고 가정이 잘못된 것으로 판명될 경우 예외를 포착합니다.이 깔끔하고 빠른 스타일은 많은 시도와 예외 문장이 있는 것이 특징입니다.이 기법은 C와 같은 다른 많은 언어에 공통되는 LBIL 스타일과 대조됩니다.

이러한 문단에서는 단지 다음과 같이 기술하였다.

def make_some_noise(speaker):
    if hasattr(speaker, "quack"):
        speaker.quack()

다음과 같은 것이 바람직합니다.

def make_some_noise(speaker):
    try:
        speaker.quack()
    except AttributeError:
        logger.warning("This speaker is not a duck")

make_some_noise(DonaldDuck())  # This would work
make_some_noise(DonaldTrump())  # This would trigger exception

어쩌면 시도조차 생략할 수도 있고제외:

def make_some_noise(duck):
    duck.quack()

그래서, EAFP는 오리타입을 장려한다.그러나 흐름 제어에 대한 예외 사용은 권장하지 않습니다.

질문 3: 어떤 상황에서 예외를 발생시키는 프로그램을 설계해야 합니까?

예외를 제어 흐름으로 사용하는 이 안티 패턴인지에 대한 무트컨버세이션입니다왜냐하면, 일단 주어진 기능에 대한 설계 결정이 내려지면, 그 사용 패턴도 결정되기 때문에, 발신자는 그 방법으로 그것을 사용할 수 밖에 없기 때문입니다.

이제 기본 설정으로 돌아가서 함수가 값을 반환하거나 예외를 발생시킴으로써 결과를 생성하는 것이 더 나은 경우를 살펴보겠습니다.

반환값과 예외의 차이점은 무엇입니까?

  1. 그들의 "폭발 반지름"은 다르다.반환값을 사용할 수 있는 것은 직접 발신자뿐입니다.예외는, 검출될 때까지 무제한의 거리에 대해서 자동적으로 릴레이 할 수 있습니다.

  2. 들르반환 값은 정의상 하나의 데이터입니다(사전이나 컨테이너 개체와 같은 복합 데이터 유형을 반환할 수 있더라도 기술적으로 하나의 값입니다).반대로 예외 메커니즘에서는 여러 값(한 번에 하나씩)을 각각의 전용 채널을 통해 반환할 수 있습니다. 각각 「」, 「」except FooError: ... ★★★★★★★★★★★★★★★★★」except BarError: ...블록은 전용 채널로 간주됩니다.

따라서 각각의 시나리오에 따라 적합한 하나의 메커니즘을 사용할 수 있습니다.

  • 통상적인 케이스는 모두 반환값으로 반환하는 것이 좋습니다.발신자는 반환값을 즉시 사용해야 할 가능성이 높기 때문입니다.반환값 어프로치에서는, 기능하는 프로그래밍 스타일로 발신자의 레이어를 네스트 할 수도 있습니다.예외 메커니즘의 긴 폭발 반경과 다중 채널은 여기에 도움이 되지 않습니다.를 들어, 어떤 가 '아까', '아까', '아까', '아까', '아까'라고 해도 의미가 .get_something(...)는 예외로서 해피 패스 결과를 생성합니다.(이것은 실제로 의도된 예가 아닙니다.구현해야 할 한 가지 방법이 있습니다.BinaryTree.Search(value)(예외를 사용하여 깊은 재귀의 중간에 값을 반송합니다.)

  • 발신자가 반환값에서 송신된 에러를 처리하는 것을 잊어버렸을 가능성이 있는 경우는, 예외의 문자 #2 를 사용해 발신자를 숨겨진 버그로부터 보호하는 것을 추천합니다.인 예가 '입니다.position = find_string(haystack, needle), 도 반환값 '''는 ''''입니다-1 ★★★★★★★★★★★★★★★★★」null발신자에게 버그를 일으키는 경향이 있습니다.

  • 오류 sentinel이 결과 네임스페이스의 일반 값과 충돌하는 경우, 해당 오류를 전달하려면 다른 채널을 사용해야 하므로 예외를 사용하는 것이 거의 확실합니다.

  • 정상 채널, 즉 반환값이 happy-path에서 이미 사용되고 있고 happy-path에 복잡한 흐름 제어가 없는 경우 흐름 제어에 예외를 사용할 수밖에 없습니다.은 Python이 Python을 어떻게 에 대해 하고 있다.StopIteration반복 종료에 대한 예외와 "흐름 제어에 대한 예외 사용"을 정당화하기 위해 사용합니다.그러나 IMHO는 특정 상황에서만 실용적인 선택일 뿐 "흐름 제어에 예외 사용"을 일반화하거나 미화하지는 않습니다.

의 기능이 되어 있는지 get_stock_price() 그 되어 있는 """를 쓸 수 .calculate_market_trend() 「 」를 get_stock_price()calculate_market_trend()당신의 비즈니스 논리가 그렇게 하도록 요구하느냐의 문제일 뿐입니다.만약 그렇다면, 그렇게 하고, 그렇지 않다면 예외를 더 높은 레벨로 버블링합니다(이는 예외의 특성 #1 "긴 블라스트 반지름"을 활용합니다).

, 레이어 를 실장하고 있는 는,Foo .Bar、 「 「 」 、 「 」를 모두 취득하는 것으로, 의 상세를 숨길 수 Bar.ThisError,Bar.ThatError에 them them them them them them them 로 매핑합니다.Foo.GenericError이긴 우리에게하므로, "가 반환 할 수 . 이 경우, 긴 폭발 반경이 실제로 우리에게 불리하게 작용하므로, "라이브러리 바가 반환 값을 통해 오류를 반환하는 경우에만" 희망할 수 있습니다. 그 은 오래 .Bar그참참참 참고고요요 요요요요 。

전체적으로 예외로 컨트롤 플로우를 할지는 미해결점이라고 생각합니다.

OP, 정답입니다.Python에서의 시도 후/제외는 추하다.불필요한 다른 흐름 제어 객체로 이어집니다.

try:
    x = blah()
except:
    print "failed at blah()"
else:
    print "just succeeded with blah"

완전히 분명한 등가물은 다음과 같습니다.

try:
    x = blah()
    print "just succeeded with blah"
except:
    print "failed at blah()"

이것은 다른 조항보다 훨씬 명확하다.그 외 시행/제외는 자주 작성되지 않기 때문에 그 의미를 파악하는 데 시간이 걸립니다.

당신이 무언가를 할 수 있다고 해서, 당신이 어떤 것을 해야 한다는 것을 의미하지는 않습니다.

누군가가 그것이 유용할 것이라고 생각했기 때문에 많은 기능들이 언어에 추가되었다.문제는 기능이 많을수록 명확하지 않고 명확하지 않다는 것입니다. 왜냐하면 사람들은 보통 이러한 종과 휘파람을 사용하지 않기 때문입니다.

여기 내 5센트만 있어나중에 읽고 수정하는 것이 귀찮아질 때 스스로 똑똑하다고 생각하고 매우 정확하고 효율적인 방법으로 코드를 작성하려는 대학 개발자 중 1학년이 작성한 많은 코드를 정리해야 합니다.나는 매일 읽기에 투표하고 일요일에는 두 번 읽기에 투표한다.

언급URL : https://stackoverflow.com/questions/16138232/is-it-a-good-practice-to-use-try-except-else-in-python

반응형