4

API ライブラリをクリーンアップし、未処理の例外を処理する最善の方法を見つけようとしています。

現在、このライブラリは、API で問題が発生する可能性のあるほぼすべてのエラー (資格情報エラー、サーバー エラー、urllib2 エラー、httplib エラーなど) をキャッチします。特殊なケースもあります。

私の現在の考えでは、ライブラリ ユーザーの 99% は例外自体は気にせず、API 呼び出しが失敗したことだけを気にしています。例外を気にするのは開発者だけです。

それは私をこの解決策に導きます:

class ApiError(Exception):
    pass

class ApiUnhandledError(ApiError):
    pass

API の既知の問題により、ApiError または特定のサブクラスが発生します。

それ以外の場合はすべて ApiUnhandledError が発生し、元のエラーが隠されます。ユーザーはこれをキャッチまたは無視できます。

try:
    stuff
except urllib2.UrlError , e :
    raise ApiError(raised=e)
except Exception as e :
    raise ApiUnhandledError(raised=e)

これは、開発者がサポートの方法を維持できる一方で、ユーザーが合格/不合格のみを認識できるようにするための良いアプローチのように思えますか?

アップデート

ベスト プラクティスのコンセンサスに基づいて、これをトラップするつもりはありません。

当初の目標は、人々がこれを行えるようにすることでした:

try:
   stuff_a
   other_stuff
   even_more_stuff

   api.proxy(url)

   again_stuff
   again_others
 except api.ApiUnhandledError , e :
    handle error
 except api.ApiError , e :
    handle error
 except Stuff , e :
     other error
 except:
     raise

その例では、ユーザーは ApiError (およびオプションで ApiUnhandledError またはその他のサブクラス) をキャッチするだけで済みます。

これは、独自のブロックを持つすべての API インタラクションよりもはるかに好ましいと思いました。

try:
   stuff_a
   other_stuff
   even_more_stuff

   try:
       api.proxy(url)
     except api.ApiError , e :
        handle error
     except CatchSomething1 , e :
        handle error
     except CatchSomething2 , e :
        handle error
     except CatchSomething3 , e :
        handle error
     except CatchSomething4 , e :
        handle error
     except:
        raise

   again_stuff
   again_others
 except Stuff , e :
     other error
 except:
     raise

urllib2 を扱うとき、私は毎日新しい例外を発見しているようです。これらの例外は非常に長くなり、保守が困難になる傾向があります。

4

1 に答える 1