こんにちはハブラ 今日は、C＃開発者が直接アクセスできないCLRメカニズムの1つ、例外フィルターについて説明します。
私の友人のC＃プログラマーの調査では、彼らが（もちろん）このメカニズムを使用したことがなく、その存在についても知らないことが示されました。 したがって、私はすべての好奇心の強い人に記事のテキストを読むように勧めます。
そのため、例外フィルターは、
catchが、このブロックでキャッチされるために例外が満たさなければならない前提条件
catch宣言できるメカニズムです。 このメカニズムは、
catch内でチェックを実行するようには機能しませ
ん 。
カットの下には、VB.NET、F＃、CIL、およびC＃コード、およびフィルターメカニズムを処理するためのさまざまな逆コンパイラーのチェックがあります。
例外フィルターがある場合
例外フィルターはCLRに組み込まれており、例外を処理するときに環境が使用するメカニズムの1つです。 シーケンスは次のとおりです。
適切な
catchの検索フェーズでは
catch CLRは例外ハンドラーの内部スタックをクロールし、例外フィルターも実行します。 これは、
finallyブロックでコードが実行される
前に発生
すること
に注意してください。 この点については後で説明します。
VB.NETでの表示
VB.NET言語でネイティブにサポートされている例外フィルター。 フィルターを使用するコードの例を次に示します。
Sub FilterException() Try Dim exception As New Exception exception.Data.Add("foo", "bar1") Console.WriteLine("Throwing") Throw exception Catch ex As Exception When Filter(ex)
このコードが実行されると、次のメッセージチェーンが発行されます。
Throwing Filtering Caught Finally
F＃での表示
この記事を準備する中で、F＃が例外フィルターをサポートしていることをインターネットで発見しました。 まあ、それをチェックしてください。 サンプルコードを次に示します。
F＃のコード open System let filter (ex : Exception) = printfn "Filtering" ex.Data.["foo"] :?> string = "bar" let filterException() = try let ex = Exception() ex.Data.["foo"] <- "bar" printfn "Throwing" raise ex with
このコードは、通常の
catch [mscorlib]System.Objectを使用して、フィルターなしでコンパイルします。 F＃コンパイラーで例外フィルターを作成することはできませんでした。 これを行う別の方法を知っている場合は、コメントを歓迎します。
CILでの表示
CIL（Common Intermediate Language）は、.NETマシンの低レベルアセンブリ言語に類似しています。 コンパイルされたアセンブリは、
ilasmツールを使用してこの言語に分解し、.NETに同
ilasmれている
ilasmを使用して
ilasmことができます。
ildasm見たVB.NETのコードスニペットを以下に
ildasmます。
多くのCILコード .method public static void FilterException() cil managed {
ご覧のとおり、VB.NETコンパイラーはもちろん、コードをCILの形式で大きく塗りつぶしました。 最も興味があるのは
filterブロックです。
filter {
そのため、コンパイラーは、フィルターブロックで例外の種類のチェックと、関数の呼び出しを発行しました。 フィルターブロックの実行の最後に値
1スタックにある場合、このフィルターに対応する
catchブロックが実行されます。 それ以外の場合、いいえ。
C＃コンパイラーは
filterブロックで型チェックを行わず、型を示す特別なCIL構造を使用することに注意してください。 つまり、C＃コンパイラは
filterメカニズムをまったく使用しません。
ところで、このブロックを生成するには、
ILGenerator.BeginExceptFilterBlockメソッドを使用できます（独自のコンパイラを作成している場合）。
逆コンパイラでの表示
このセクションでは、いくつかの有名なツールを使用して結果のコードを逆コンパイルし、何が起こるかを確認します。
最新の
JetBrains dotPeek 1.1は 、フィルターを使用してアセンブリを逆コンパイルしようとしたときに、次のことを喜んで報告しました。
public static void FilterException() {
.NET Reflector 8.2はより適切に動作し、C＃で何かを逆コンパイルできました。
public static void FilterException() { try { Exception exception = new Exception(); exception.Data.Add("foo", "bar"); Console.WriteLine("Throwing"); throw exception; } catch when (?) { Console.WriteLine("Caught"); ProjectData.ClearProjectError(); } finally { Console.WriteLine("Finally"); } }
まあ、悪くない-コードはコンパイルされていませんが、それによってフィルターを見ることができます。 フィルターが復号化されなかったという事実は、C＃トランスレーターの欠点に起因する可能性があります。 VB.NETのトランスレーターでも同じことを試してみましょう。
Public Shared Sub FilterException() Try Dim exception As New Exception exception.Data.Add("foo", "bar") Console.WriteLine("Throwing") Throw exception Catch obj1 As Object When (?) Console.WriteLine("Caught") ProjectData.ClearProjectError Finally Console.WriteLine("Finally") End Try End Sub
残念ながら、この試みは同じように失敗しました-何らかの理由で、逆
ildasmはフィルター関数の名前を判別できませんでした（ただし、上記で見たように、
ildasmは素晴らしい仕事をしました）。
ここで説明したツールは、.NET4.5フィルターコードではうまく機能しないと推測できます。
これは、 catch本体のチェックとどのように違いますか
VB.NETコードと
ほぼ同様のコードを考えてみましょう。
C＃コード static void FilterException() { try { var exception = new Exception(); exception.Data["foo"] = "bar"; Console.WriteLine("Throwing"); throw exception; } catch (Exception exception) { if (!Filter(exception)) { throw; } Console.WriteLine("Caught"); } } static bool Filter(Exception exception) { return exception.Data["foo"].Equals("bar"); }
次に、C＃とVB.NETの例の動作の違いを見つけてみましょう。 とても簡単
throw; ：
throw; C＃では、スタック上の行番号が失われます。
false返すようにフィルターを変更すると、アプリケーションはメッセージでクラッシュします
Unhandled Exception: System.Exception: Exception of type 'System.Exception' was thrown. at CSharpFilter.Program.FilterException() in CSharpFilter\Program.cs:line 25 at CSharpFilter.Program.Main(String[] args) in CSharpFilter\Program.cs:line 9
スタックから判断すると、19行目（
throw exception; throw; ）ではなく、25行目（ラインの
throw; ）で例外がスローされました。 同じ条件下でのVB.NETコードは、例外の最初の場所を示しています。
UPD。 当初、私は誤ってその
throw;書きました
throw; スタック全体が失われますが、コメントでは、これは実際にはまったくないことが示唆されています。 スタックの行番号にわずかな変更のみがあります。 さらに、これはモノでは再生されません-例外スタックは
throw;後に変更されません
throw; （これらの詳細については
kekekeksに感謝し
ます ）。
セキュリティについて
ブログのEric Lippertは、例外フィルターにより、悪意のある側が昇格した特権でコードを実行できる場合がある
と考えています。
要するに、外部の潜在的に破壊的なコードに対して一時的な特権エスカレーションを実行している場合、
finallyに依存することはできません。
finallyブロックを実行する前に、コールスタックの上にある例外フィルターを呼び出すことができます（そして、攻撃者はこれらのフィルターのコードで何でもできます）。 要確認-正しい
catch見つけることは、
finallyブロックが実行される
前に必ず行われます。
おわりに
今日は、C＃でめったに出会わないCLRプログラマーの1人に注目しました。 私自身はVB.NETには書き込みませんが、この情報は.NETプラットフォームのすべての開発者に役立つと信じています。 このプラットフォーム用の言語、コンパイラ、またはデコンパイラを開発している場合、この情報は特に役立ちます。
PS。 コード、画像、記事のテキストはgithub：
github.com/ForNeVeR/ClrExceptionFiltersに投稿されています。