C言語のコンパイラエラー C2702について解説

この記事では、C言語で発生するコンパイラエラーC2702について説明します。

__exceptが最終ブロックに配置されたり、__finallyブロック内で__try/__exceptを入れ子にするとエラーが発生します。

具体例を参考に、正しい例外ハンドリングの実装方法の理解に役立つ内容です。

エラー発生の背景と基本構文

__finallyブロックの役割と制約

__finally ブロックは、例外の有無にかかわらず必ず実行されるクリーンアップ用のブロックです。

たとえば、メモリの解放やファイルハンドルのクローズなど、後始末の処理を記述する際に用いられます。

しかし、__finally ブロック内に __try や __except ブロックを入れ子にすることはできません。

この制約に違反すると、コンパイラはエラー C2702 を出力します。

このルールは、例外ハンドリングの整合性を保つために設けられており、構文の明確さを維持する役割を果たしています。

__try/__except構文の基本ルール

__try ブロックは例外が発生する可能性のあるコードを囲むために使われ、続く __except ブロックで例外処理を実装します。

__except 内では例外の条件やフィルタ式を指定でき、例外発生時の処理が記述されます。

通常、__try と __except はペアで用いられ、一方のブロック内に別の __try/__except を入れ子にすることは制限されています。

また、__except ブロック自体を __finally の最終ブロックとして配置することはできません。

これらのルールに沿って記述することで、明確で予測しやすい例外処理が実現できるようになっています。

C2702エラーの発生原因

__exceptを最終ブロックに配置した場合の問題点

C2702 エラーは、例外ハンドラーである __except ブロックが最終ブロックとして配置されている場合に発生します。

具体的には、__finally ブロック内や別の文脈で __except ブロックを最終の処理として使用すると、コンパイラがその位置付けを正しく認識できず、エラーが出力されます。

このルールは、例外処理の構造が混乱しないように設けられており、最終ブロックにおいては __finally を用いる必要があることを示しています。

__finally内での入れ子構造の制限

__finally ブロック内に __try/__except の入れ子構造を作成すると、構文解析が複雑になり、正しい例外処理の流れが分かりにくくなります。

そのため、Microsoftのコンパイラは __finally 内での __try や __except の入れ子構造を禁止しています。

この制限に違反すると C2702 エラーが発生し、開発者はコードの構造を見直す必要があります。

基本的には、__finally は単一のクリーンアップ処理として記述し、例外処理は __try/__except ブロックで別に管理するよう設計することが求められます。

コード例によるエラー検証

問題となるNGコード例

__exceptが最終ブロックに配置されたケース

以下のコードは、__except ブロックを __finally ブロック内の最終部に配置しているため、C2702 エラーが発生します。

#include <windows.h>
#include <stdio.h>
int globalCounter = 0;
int main(void) {
    __try {
        // メイン処理(例: 処理ループなど)
    }
    __finally {
        // __finally 内に __try/__except をネストしているためエラーが発生する
        __try {
            // 追加処理
        }
        __except(globalCounter) {
            // 例外処理
        }
    }
    return 0;
}

// C2702 エラー: "__except が最終ブロックにあってはなりません。"

__try/__exceptの入れ子構造の例

次のコードも、__finally ブロックの中に __try/__except を入れ子にしているため、正しく動作しません。

#include <windows.h>
#include <stdio.h>
int exceptionFilter(int filterValue) {
    // フィルター条件を評価
    return filterValue != 0;
}
int main(void) {
    __try {
        // メイン処理
    }
    __finally {
        // 入れ子になった __try/__except はエラーとなる
        __try {
            // 追加処理
        }
        __except(exceptionFilter(1)) {
            // 例外処理
        }
    }
    return 0;
}

// C2702 エラー: "例外ハンドラーは __finally ブロック内に入れ子にできません。"

修正されたコード例と解説

正しい例外ハンドリングの実装例

正しい実装例では、__finally ブロックはあくまでクリーンアップのための単一ブロックとして使用し、例外処理は __try / __except ブロック内で行います。

下記のコードは、例外処理とクリーンアップ処理を分離した正しい例です。

#include <windows.h>
#include <stdio.h>
// 例外フィルター関数
int exceptionFilter(int filterValue) {
    return filterValue != 0;
}
int main(void) {
    __try {
        // 例外が発生する可能性のある処理
        printf("メイン処理を実行中...\n");
        // ここで何らかの例外が発生する可能性がある
    }
    __except(exceptionFilter(1)) {
        // 例外処理
        printf("例外が発生しました。\n");
    }
    // クリーンアップの処理は __finally を用いる代わりに、正常系以降で行う
    // または、必要ならば __try ブロックの後に別途クリーンアップ処理を記述する
    printf("クリーンアップ処理を実行中...\n");
    return 0;
}

メイン処理を実行中...
クリーンアップ処理を実行中...

この正しい例では、例外が発生した場合、__except ブロック内で処理が行われ、基本処理後に共通のクリーンアップ処理を実施するように記述しています。

これにより、各ブロックの役割が明確になり、エラー C2702 を回避することができます。

エラー回避のポイント

コンパイラエラーメッセージの読み解き方

コンパイラのエラーメッセージは、コード内のどの部分がルールに違反しているかを明確に示しているため、必ず内容を確認してください。

たとえば、C2702 エラーの場合、「__except が最終ブロックにあってはなりません」といった具体的なヒントが表示されます。

エラーメッセージを元に、コードのブロック構造を見直し、__finally ブロック内に不要な入れ子が含まれていないかをチェックすることが重要です。

開発環境でのチェックすべき構文ルール

開発環境では、以下の点を確認することでエラーの発生を防げます。

• __try と __except、および __finally の基本ルールに則った記述を行う。
• __finally ブロック内には例外ハンドラーを含めない。
• ソースコードをコンパイル前にスタティック解析ツールやコンパイラの警告メッセージでチェックする。
• マイクロソフトの公式ドキュメントやリファレンスを参照し、最新の構文ルールを確認する。

これらのポイントを確認することで、例外処理に関するエラーが発生しにくい健全なコードを作成することができます。

まとめ

この記事では、Windows環境で利用される例外処理構文の基本的な役割やルール、特に__finallyブロックと__try/__exceptの使い方を解説しています。

C2702エラーの原因として、__finallyブロック内での入れ子構造および__exceptブロックの最終配置の問題点を示し、NGコード例と正しい実装例を通じてエラーを回避する方法を学びました。