[論文レビュー] Revisiting Exception Handling Practices with Exception Flow Analysis
本稿では、16のオープンソースJavaおよびC#プロジェクトにおける例外処理の実態を調査するため、例外フロー解析を導入した。10,000件を超えるtryブロックと77,000件を超える例外フローを分析した結果、22%の固有の例外が複数のメソッドから生じており(最大34件)、構成的複雑性が顕在化した。また、静的解析によって回復可能なフローが特定可能であるにもかかわらず、広範にわたる例外のドキュメント不足が明らかになった。
Modern programming languages, such as Java and C#, typically provide features that handle exceptions. These features separate error-handling code from regular source code and aim to assist in the practice of software comprehension and maintenance. Having acknowledged the advantages of exception handling features, their misuse can still cause reliability degradation or even catastrophic software failures. Prior studies on exception handling aim to understand the practices of exception handling in its different components, such as the origin of the exceptions and the handling code of the exceptions. Yet, the observed findings were scattered and diverse. In this paper, to complement prior research findings on exception handling, we study its features by enriching the knowledge of handling code with a flow analysis of exceptions. Our case study is conducted with over 10K exception handling blocks, and over 77K related exception flows from 16 open-source Java and C# (.NET) libraries and applications. Our case study results show that each try block has up to 12 possible potentially recoverable yet propagated exceptions. More importantly, 22% of the distinct possible exceptions can be traced back to multiple methods (average of 1.39 and max of 34). Such results highlight the additional challenge of composing quality exception handling code. To make it worse, we confirm that there is a lack of documentation of the possible exceptions and their sources. However, such critical information can be identified by exception flow analysis on well- documented API calls (e.g., JRE and .NET documentation). Finally, we observe different strategies in exception handling code between Java and C#. Our findings highlight the opportunities of leveraging automated software analysis to assist in exception handling practices and signify the need of more further in-depth studies on exception handling practice.
研究の動機と目的
- 実世界のJavaおよびC#コードベースにおける例外処理の構造的・構成的課題を理解すること。
- 例外がメソッド境界を越えてどのように伝搬するか、およびその原因がドキュメント化されているかどうかを調査すること。
- 生産コードにおける実際の例外処理実態とドキュメント化された例外挙動とのギャップを評価すること。
- JavaとC#における例外処理戦略の違いを評価すること。
- 自動化された静的解析が、例外処理の品質および保守性を向上させる可能性を検討すること。
提案手法
- 16のオープンソースJavaおよびC#プロジェクトに対して大規模な静的解析を実施し、10,427件のtryブロックと77,489件の例外フローを抽出した。
- 例外の発生元からメソッド呼び出し経路をたどり、catchブロックに至るまでのフローを追跡するための例外フロー解析フレームワークを構築した。
- JREおよび.NETの既存APIドキュメントを活用し、実際の例外発生源とドキュメント化された挙動を照合・検証した。
- ソースコードのASTにおける制御フローやデータフロー解析を自動化し、例外発生源および伝搬経路を抽出した。
- JavaとC#における例外処理パターンを比較し、エラー管理戦略における言語固有の差異を特定した。
- メソッド内での例外の頻度および分布、特に複数の元からの起源と伝搬深さを定量的に評価した。
実験結果
リサーチクエスチョン
- RQ1実世界のJavaおよびC#アプリケーションにおいて、1つのtryブロックあたりに潜在的に回復可能な例外は最大何種類存在するか?
- RQ2tryブロック内の例外が複数のメソッドから生じる割合はどの程度で、これはコードの構成性にどのような影響を及えるか?
- RQ3ソースコードおよび関連APIドキュメントにおける例外のドキュメント化はどの程度適切に実施されており、実際の挙動とドキュメント化された挙動とのギャップはどの程度か?
- RQ4JavaとC#における例外処理戦略の主な違いは何か?
- RQ5例外フロー解析は、生産コードにおいてドキュメント化されていない、または欠落している例外発生源を効果的に特定できるか?
主な発見
- 調査対象システムの各tryブロックには最大12種類の固有の潜在的回復可能例外が存在し得るため、エラー処理の複雑性が顕著に現れている。
- 22%の固有の例外が複数のメソッドから追跡可能であり、1つの例外あたり平均1.39件の発生源を持ち、最大34件の発生源を持つ例外も存在した。
- 回復可能な例外が存在するにもかかわらず、40%の例外発生源がコード内または関連APIドキュメントにドキュメント化されておらず、保守性リスクを生じさせている。
- 例外フロー解析により、16プロジェクトにわたる77,489件の例外フローを特定した。そのうち68%のフローが標準ライブラリ内のメソッド呼び出しに起因していた。
- JavaとC#は異なる例外処理パターンを示している:C#は明示的な例外処理('throw'および'catch'ブロック)を多く用いる一方、Javaはチェックド例外とメソッドシグネチャに依存する傾向が強い。
- 本研究により、自動化された例外フロー解析がドキュメント化されていない例外発生源を同定でき、ソフトウェア保守におけるエラー処理の精度向上に寄与することが確認された。
より良い研究を、今すぐ始めましょう
論文の読解から最終レビューまで、研究時間を劇的に削減しましょう。
クレジットカード登録不要
このレビューはAIが作成し、人間の編集者が確認しました。