2

カスタム例外を発生させることができるいくつかのメソッドがあります。例外が発生した後、それを処理する必要があります。たとえば、メッセージをコンソールに記録してデータベースに保存します。

投稿のタイトルに記載されているクレイジーな回避策について考えていました-ロギングとDB保存を使用してそのカスタムコードを__init__カスタム例外のメソッドに移動できるため、例外が発生するたびに、必要なものはすべて例外の初期化時に行われます。

__init__例外自体が別の例外を発生させる可能性があることは承知していますが、それも処理できます:)

誰かがそれを試しましたか？

そして、なぜそれはクレイジーな考えですか？:)

-

編集：

私はそれがちょっとクレイジーであることを知っています、私はあなたの意見に興味があります. 私が達成したいことを囲みます：

私はリモートデータを扱っており、ネットワークを介して他のサーバーと通信しているときに、いくつかの問題が発生する可能性があります。2. HTTP エラー (404、500 など) - 接続後。3. リモート サーバーが他のエラーを返すこともあります

これらの問題はいくつかの異なる場所で発生するため、カスタム例外を作成しました。

class CustomException(Exception):
    pass

そして、私がそれらを捕まえることができるとき、どこでもそれを上げます、例えば:

try:
    conn.open(url)
except HTTPException as e:
    raise CustomException('http')

それは単なる疑似例です。

この CustomException はどこか高くキャッチされ、ほぼすべての場所でこれを同じ方法で処理します。

try:
     place.populate()
except CustomException as e:
     handle_exception(e)
     return False

また、問題に関する情報をデータベースに保存し、のオブジェクトの状態やアクセス日をhandle_exception保存するなどの他のことも行いますが、常に同じことを更新します。place

handle_exceptionそのため、例外が発生するたびにコードが実行されるため、そのコードを内部__init__に配置するのは本当にクレイジーなアイデアになるのではないかと思っていました。

ご意見ありがとうございます！

4

2 に答える 2

1

あなたは2つの別々のことを提案しているようです。まず、例外内にいくつかのカスタム コードを含めるというアイデアがあります。これはクレイジーではなく、かなり実行可能です。

例：

class CustomException(Exception):
    def __init__(self, message, Errors):
        # do stuff here

ただし、例外が発生するたびに例外を自動的にキャッチすることをほのめかしました。実行しない理由は非常に単純です。エラーでない場合は、例外にしないでください。ある時点で実際に何かをする予定がない場合、クラスを例外にする理由があるとは想像できません。

個人的には、例外を発生させるための実質的なロジックが必要な場合 (特定の目標を知らずにこれについてコメントするのは少し難しい)、__init__メソッドにロガーを配置してから、ロジックを直接 に直接配置することをお勧めしtry/exceptます。 .

于 2013-07-02T13:54:18.363 に答える
1

他の人が言ったように、このようなことをする場合、これは疑わしい目標ですが、logging.Logger例外のを介してメッセージをルーティングし、DB へのログ記録、コンソールへの出力などのためにs__init__を添付することをお勧めします。欲しいです。これにより、ライブラリのユーザーは、はるかに簡単で標準化された方法でシステムを制御 (および拡張) できます。logging.Handler

于 2013-07-02T13:57:15.970 に答える