1

exit()関数内から fromするのは悪い形ですか?

def respond_OK():
    sys.stdout.write('action=OK\n\n')
    sys.stdout.flush() # redundant when followed by exit()
    sys.exit(0)

終了コードを設定して名前空間exit()から ing するのではなく?__main__

def respond_OK():
    global exit_status
    sys.stdout.write('action=OK\n\n')
    sys.stdout.flush()
    exit_status = 0

sys.exit(exit_status)

機能の観点から見ると、違いはごくわずかですが、コンセンサスがどのような形になっているのか疑問に思っただけです. 他の人のコードで事前確率を見つけた場合、それを 2 回確認しますか?

4

3 に答える 3

6

例外が発生し、メイン エントリ ポイントから処理され、その型が終了コードに変換されることを確認したいと思います。例外のサブクラス化は、Python では非常に単純で、ほとんど楽しいものです。

この回答のコメントに投稿されているように: sys.exit を使用すると、発生したエラーの種類ではなく、終了ポイントが実際のステータス コードを知る必要があることも意味します。もちろん、それは一連の定数によって解決できますが。ただし、例外の使用には他の利点もあります。1 つの方法が失敗した場合、再入力せずに別の方法を試すか、事後分析のデバッグ情報を出力できます。

于 2012-09-17T19:13:49.957 に答える
3

かなり慣用的な場合がいくつかあります。

ユーザーが間違ったコマンドライン引数を与えた場合、次の代わりに:

def usage(arg0):
  print ... % (arg0,)
  return 2

if __name__ == '__main__':
  if ...:
    sys.exit(usage(sys.argv[0]))

あなたはよくこれを見ます：

def usage():
  print ... % (sys.argv[0],)
  sys.exit(2)

if __name__ == '__main__':
  if ...:
    usage()

私が考えることができる他の唯一の一般的なケースは、(ctypes または低レベルの C 拡張モジュールを介して) ライブラリの初期化が予期せず失敗し、理由を説明できない状態になる場合です。可能な限り (例えば、segfaulting や印刷ガベージの可能性を減らすため) 例:

if libfoo.initialize() != 0:
  sys.exit(1)

sys.exit実際にはできるだけ早くインタープリターから抜け出さない (例外をスローしてキャッチする) ため、これに反対する人もいるかもしれません。しかし、あなたはまだそれをかなり頻繁に見ています。

于 2012-09-17T19:52:10.723 に答える
3

機能面での違いはありませんが、終了につながる可能性のあるメイン名前空間からの各呼び出しにコメントを付けるなど、適切な手順を実行しない限り、コードを追跡するのが難しくなる可能性があります。

更新：例外をキャッチする効果に関する@mgilsonの回答に注意してください[発生する例外をキャッチして、system.exit終了を防ぐことができます]。そのようにして、コードをさらに混乱させる可能性があります。

更新 2: 例外を使用して終了を調整するという @saht の提案に注意してください。これは、本当に非ローカルな終了を行いたい場合に有効なアドバイスです。グローバルを設定するよりもはるかに優れています。

于 2012-09-17T19:09:33.570 に答える