PythonでGDALに例外を適切に発生させる方法はありますか？

私はPythonでGDALを使用していますが、GDALで例外を発生させて、有用なことを行えるようにしたいと考えています。たとえば、gdal.Open（）でファイルを開くことができない場合、gdalがNoneを返す代わりに例外をスローしたいと思います。エラーをsys.stdoutにダンプするのではなく、キャプチャする方法が欲しいのです。

現在、このgdal.UseExceptions()関数を使用しようとしましたが、問題に遭遇しました。ときにgdal.UseExceptions()設定されていることは、特定のエラーを隠し、それらに例外を発生させないように思われます。たとえば、ERROR 5: Access window out of range in RasterIO() Requested (1,15) of size 25x3 on raster of 26x17消えて例外は発生しません。これはかなり危険なようです。

どんなアイデアでも感謝します、ありがとう。

— ダグ
ソース

Doug-今朝OGR / Postgresエラーについて尋ねた質問とよく似ています（以下のリンク）。GDALエラーの問題を処理する（ハック的な）方法は、GDAL / OGRに接続するすべてをNoneに設定し、カスタムエラークラスを使用して、接続に関する特定のエラーを発生させることです。なし。 gis.stackexchange.com/questions/30607/…–

— トマス

以下のコメントで推奨されているようにチケットを提出しました。ここで追跡できます：（trac.osgeo.org/gdal/ticket/4800）

— ダグ

/*
** We do not want to interfere with warnings or debug messages since
** they won't be translated into exceptions.
*/
if (eclass == CE_Warning || eclass == CE_Debug ) {
    pfnPreviousHandler(eclass, code, msg );
}

UseExceptionsハンドラーは、CE_ErrorまたはCE_Fatal以外をリッスンしません。表示されているのは、おそらくCE_WarningまたはCE_Debugメッセージです（関数呼び出しの戻り値をチェックして、それが何であるかを確認してください）。

この妥協は、「新しい」Pythonバインディングが「古い」Pythonバインディング（すべてのエラー処理を手動で行い、戻りチェック型である）と同様に動作するようにするために行われました。私はこの種の吸い込みに同意します。

チケットを提出して、例外ハンドラがリッスンするレベルを追加できるようにしてください、ala

UseExceptions(level=CE_Warning)
UseExceptions(level=CE_Debug)

— ハワード・バトラー
ソース

返信いただきありがとうございます。これはまったく理にかなっています。チケットを提出して、リンクをここに投稿しようと思います。

— ダグ