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