JPH06324885A

JPH06324885A - 例外条件処理方法及び装置

Info

Publication number: JPH06324885A
Application number: JP6031210A
Authority: JP
Inventors: Edward Benson Frank; フランク・エドワード・ベンソン; Daniel Rodman Hicks; ダニエル・ロッドマン・ヒックス
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1993-03-15
Filing date: 1994-03-01
Publication date: 1994-11-25
Anticipated expiration: 2011-08-21
Also published as: US5761407A; JP2526020B2

Abstract

(57)【要約】【目的】本発明の主目的は、従来技術における「デッ
ド・ルーチン」の問題を解決しながら、「終了」言語モ
デルと「非終了」言語モデルをサポートする、機能強化
された方法及び装置を提供することである。【構成】従来技術の内部化の問題に関して、本発明で
使用する解決策は、システム・レベルの例外管理ルーチ
ンの局所記憶域から独立した、個々の例外事例に関する
情報をデータ構造内に維持する。これによって、例外処
理機構全体が、システム・レベルの例外管理ルーチンの
コール／リターン・フローから独立にこれらのデータ構
造の操作に関して記述し指定することができるようにな
るので、混乱やあいまいさがなくなる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はデータ処理の分野に関す
る。さらに詳しくは、本発明はコンピュータ・システム
内でのエラー／例外処理に関する。

【０００２】

【従来の技術】本発明は、１９９１年９月６日出願の"P
rogram Condition Handling"と題する米国特許出願第７
５５７０６号（対応する日本国特許出願平４−２２２６
５２号）に関係する。これを以下関連出願Ｉと称する。

【０００３】本発明はまた、１９９１年９月６日出願
の"Method and System for Representing and Signalin
g Run-Time Program Conditions"と題する米国特許出願
第７５５７０８号（対応する日本国特許出願平４−２２
２６４０号）にも関係する。これを以下関連出願IIと称
する。

【０００４】１９４８年のＥＤＶＡＣコンピュータ・シ
ステムの開発が、しばしばコンピュータ時代の始まりと
して引用されている。この時以来、コンピュータ・シス
テムは米国のライフ・スタイルのほぼあらゆる面に浸透
してきた。この普及の理由の一つは、コンピュータ・シ
ステムが様々なタスクを効率的に実行できることであ
る。コンピュータ・システムがこうしたタスクを実行す
るために使用する機構を、コンピュータ・プログラムと
呼ぶ。

【０００５】「コール／リターン・スタック」が、コン
ピュータ・システムがコンピュータ・プログラムにそれ
ぞれのタスクを実行させ、それによってそうしたタスク
を実行するための基本的手段である。実行のためにコン
ピュータ・プログラムが実行されると、コンピュータ・
システムはその特定のコンピュータ・プログラムに関す
るクリティカルな情報を追跡するためのレコードを作成
する。これらのレコードを活動化レコードと呼ぶ。この
第１のコンピュータ・プログラムが別のコンピュータ・
プログラムを呼び出すと、コンピュータ・システムはそ
の第２のコンピュータ・プログラムを表す別の活動化レ
コードを作成する。さらに別のコンピュータ・プログラ
ムの呼出しが行われるたびに、このプロセスが繰り返さ
れる。この一連の呼出しの結果得られる活動化レコード
は、互いに論理的に「スタック」されると言われる
（「コール／リターン・スタック」の名前はそれに由来
する）。一般に新しい活動化レコードはこのコール／リ
ターン・スタック（以下スタックと称する）の一番上に
置かれると考えられる。その活動化レコードがスタック
の一番上にあるルーチンを、「走行プログラム」と呼
ぶ。

【０００６】スタック上のコンピュータ・プログラムを
維持し操作するための機構の設計は比較的単純である
が、この枠組の内部でエラーを容易にかつ効率的に処理
する能力は以前から課題であった。この問題に対する従
来の解決策は、「リターン・コード」を使用するもので
ある。リターン・コードとは、他のルーチンの呼出しか
ら戻され、呼び出されたルーチンが首尾よく完了したか
否かを示すパラメータである。リターン・コードはま
た、障害が実際に発生した場合に障害の原因を示すこと
もできる。リターン・コード方式はある状況では有効な
解決策となるが、いくつかの重大な欠陥がある。こうし
た欠陥には、リターン・コード・パラメータの設定、受
渡し、検査に伴うコスト、（リターン・コード中で提供
される以外の）エラー情報の喪失、及びエラーを「オン
・ザ・フライ」で訂正し障害を発生したルーチンを続行
させる能力がないことがある。

【０００７】こうしたリターン・コード方式に固有の諸
問題を解決するため、いくつかのマシン、オペレーティ
ング・システム及び言語は、何らかの種類の「例外」機
構を含んでいる。こうした機構は一般にいくつかの重要
な点で互いに異なるが、そのすべてが少くとも１つの基
本概念を共有している。すなわち、エラーが検出される
と、現（障害を発生した）ルーチンの実行が中断され、
多少とも「目に見えない」機構を介して「例外処理」ル
ーチンの呼出しが行われる。

【０００８】このエラー報告・処理のための例外手法は
それ自体いくつかの欠点をもつものの、「リターン・コ
ード」手法の上記の欠陥の大部分を克服する。しかし、
例外手法の主要な欠陥は、２つの実施態様に同じものま
たは特に互いに原始言語互換性のあるものがないことで
ある。具体的に言うと、ＰＬ／１、ＡＤＡ、Ｍｏｄｕｌ
ａ−３の各言語は定義済み例外モデルが相互に互換性が
なく、Ｃ言語は実際の言語構文／意味論の一部として定
義された例外モデルをもたないが、一般に、他の３者と
互換性のない例外モデルに対するライブラリ・サポート
を供給されている。したがって、こうした多様な言語を
サポートするのに十分な柔軟性を有し、かつこうした言
語が予測可能かつ妥当な形で相互に協働できる、抽象的
アーキテクチャ・モデルを定義することが、克服すべき
大きな課題である。

【０００９】非互換性の主な原因は、モデルにおける終
了意味論の有無である。ＡＤＡ言語は、例外ハンドラ
が、それが定義されているコードのルーチンまたはブロ
ックにされており、例外ハンドラの１つを呼び出す前
に、定義ルーチンから呼び出されるすべてのルーチンが
打ち切られるので、古典的な終了モデルをもつ。このこ
とは、とりわけ、ある例外が「処理」された後、元の例
外の時点から実行を再開できず、定義ルーチンまたはブ
ロックの出口点から再開しなければならないことを意味
する。

【００１０】一方、標準Ｃ言語ライブラリ・サポート
は、「非終了（nonterminating）」例外モデルを有す
る。例外が発生したとき、既に呼び出されたルーチンは
呼び出された状態に残され、例外処理ルーチンが、多少
とも例外点から呼び出されたかのように呼び出される。
このモデルでは、例外が「処理」される場合、通常、元
の例外点から実行が再開され、ＡＤＡスタイルの「終了
（termination）」は明示的なプログラマの動作を介し
てしか可能でない。

【００１１】非互換性の第２の原因は、「非終了」モデ
ルで、例外を「再信号表示」して、単一の例外に対して
再度例外を呼び出させることが可能かどうかである。Ｐ
Ｌ／１言語はその古典的な例である。未処理の例外は、
恐らくアプリケーション全体の実行が打ち切られる前に
何らかの量のクリーンアップを可能にするために、「障
害」例外として再信号表示される。しかし、この再信号
表示能力が、多くの例外モデルで問題を生じる。という
のは、例外モデルは本来「静的」であり、反復または再
入を容易にサポートしないからである。

【００１２】非互換性の第３の原因は、「例外データ」
を例外と関連付けることができるかどうかである。たと
えば、指名されたファイルが存在しないためにファイル
「オープン」動作が失敗した場合、「オープン」ルーチ
ンに提示されたファイル名を「ファイルが見つからな
い」例外と関連付けるのが（診断の目的にも回復の目的
にも）有用である。大部分の例外モデルは、こうした例
外データに対するサポートをほとんど提供しない。技術
的には、例外データの管理と追跡は、特に再通知（リシ
グナリング）をサポートする非終了モデルの場合、難し
いタスクである。というのは、反復の可能性があるとい
うことは、任意の一時点で存在する個々の例外データの
数が無制限であることを暗示するからである。

【００１３】上記の最初の２つの非互換性の問題点は、
原理的に、関連出願Ｉに記載の「２カーソル・モデル」
によって解決される。このモデルでは、各例外が一時に
スタック上の異なる可能性もある２つの活動化レコード
に関連付けられる。１つの被呼出ルーチンは、各例外の
発生に関連する「処理カーソル」によってアドレスされ
る。このルーチンは、例外が「処理された」場合にその
実行が再開されるものである。もう一方の被呼出ルーチ
ンは、各例外の発生に関連する「ハンドル・カーソル」
によってアドレスされる。このルーチンは、適切な例外
処理ルーチンを選択するために、その例外ハンドラ定義
が次に検査されるものである。

【００１４】この「２カーソル・モデル」では、「ハン
ドル・カーソル」を比較的自由に操作することができ
る。ハンドル・カーソルをルーチンからその呼出側へ移
動することを「パーコレーション（回復機能委任）」と
称し、逆の方向に（最近に呼び出されたルーチンに向か
って）移動することを、例外の「再通知」と称する。一
方、「再開カーソル」は、その動きがより限定されてお
り、より以前に呼び出されたルーチンの方向に（すなわ
ち、被呼出側から呼出側に）しか移動できず、移動され
るたびに、「脱出済み」ルーチン（以前に再開カーソル
によってアドレスされた被呼出ルーチン）が、それによ
って定義される可能性のある「終了ハンドラ」（「出口
ハンドラ」とも称する）をもつかどうか検査される。

【００１５】終了ハンドラの定義が見つかった場合、関
連するハンドラ・ルーチンが（例外ハンドラ・ルーチン
と類似の方式で）呼び出され、定義ルーチンに必要な
「クリーンアップ」を実行できるようになる。再開カー
ソルの操作に関するこれらの制限により、異常終了した
被呼出ルーチン用の終了ハンドラ・ルーチンが必ず一度
だけ呼び出されるようになる。これとは対照的に、例外
ハンドラ・ルーチンは複数回呼び出すことができ、ある
いはハンドル・カーソルの操作により全く飛び越すこと
もできる。

【００１６】関連出願Ｉに記載の従来技術の解決策によ
れば、熟練したプログラマが、あらゆるエラー条件の総
体的知識を必要とせず、かつプログラムの部分中でエラ
ー処理を行わずに、そのエラー処理の際に「頑丈な」プ
ログラムを設計することが可能になるが、大きな主要な
問題が残る。

【００１７】関連出願Ｉに記載の「２カーソル・モデ
ル」には、２つの基本的な問題がある。第一に、その記
述によればその機構は、大きな困難と複雑さなしでは、
モデルの潜在的反復／再入を管理し、なおかつ「カーソ
ル」の簡単で自由な操作を可能にすることができない。
具体的な１つの問題は、「デッド」被呼出ルーチン（カ
ーソル移動再開の結果打ち切られたルーチン）が終了し
てスタック中に留まり、せいぜい状況を「混乱させる」
だけであることがある。悪くすると、こうした「デッ
ド」被呼出ルーチンが非常に多くの記憶域を占有して、
使用可能な記憶資源がなくなってしまうこともある。

【００１８】（関連出願Ｉ及びIIで述べられている）
「２カーソル・モデル」に伴う第２の問題は、例外デー
タの内部化である。この問題は、上述の第３の非互換性
の問題（すなわち、例外データの管理）に関係する。個
々の例外事例に関する問題は、基本的に（コール／リタ
ーン・フローとは独立な分離したデータ構造としてでは
なく）システム・レベルの例外管理ルーチンの局所記憶
域中に変数として維持されるので、自由にこの情報にア
クセスしそれを管理する能力が制限され、ある種の反復
的状況では情報の記憶位置があいまいになることさえあ
る。

【００１９】

【発明が解決しようとする課題】本発明の主目的は、従
来技術の解決策に存在する「デッド・ルーチン」の問題
を解決しながら、「終了」言語モデルと「非終了」言語
モデルをサポートする、機能強化された方法及び装置を
提供することである。

【００２０】本発明の他の目的は、例外データを対象活
動から切り離して、他のプロセスからそれにアクセスで
きるようにする、機能強化された方法及び装置を提供す
ることである。

【００２１】

【課題を解決するための手段】上述の「デッド・ルーチ
ン」の問題を解決するために、本発明では、「トラッ
プ」機構を使って例外処理中の実行の流れを制御する。
本発明のトラップ機構は、特定の被呼出（ただし、現在
実行中でない）ルーチンに対してトラップをセットし
て、その被呼出ルーチンに戻るとき、直ちに制御が何ら
かのシステム・レベルの例外管理ルーチン（すなわち、
「トラップ・ハンドラ」）に戻るようにする。これは
（たとえば、あらゆる呼出しの戻り点で生成される明示
的テストを含めて）いくつかの方法で達成できるか、本
発明の機構は、被呼出ルーチンの「リターン・アドレ
ス」を、被呼出ルーチンに戻ろうと試みても、その代わ
りにシステム・レベルの例外管理コードに分岐するよう
に修正する。

【００２２】本発明のトラップ・ハンドラを用いると、
後で通知される例外を、トラップされたルーチンに制御
が戻るような時まで「保留」状態に置くことができる。
このようにして、「デッド・ルーチン」の問題が回避さ
れる。この機構は、後続の例外が処理される前にこれら
のルーチンをスタックから除去する手段を提供するの
で、「デッド・ルーチン」がスタックを混乱させること
はない。

【００２３】従来技術の内部化の問題に関して、本発明
で使用する解決策は、システム・レベルの例外管理ルー
チンの局所記憶域から独立した、個々の例外事例に関す
る情報をデータ構造内に維持するものである。これによ
って、例外処理機構全体が、システム・レベルの例外管
理ルーチンのコール／リターン・フローから独立にこれ
らのデータ構造の操作に関して記述し指定することがで
きるので、混乱やあいまいさがなくなる。

【００２４】

【実施例】図１に、本発明のコンピュータ・システムの
構成図を示す。好ましい実施例のコンピュータ・システ
ムは、拡張ＩＢＭＡＳ／４００中型コンピュータ・シ
ステムである。ただし、高水準言語をサポートするコン
ピュータ・システムならどれでも使用できる。図１の分
解図に示すように、コンピュータ・システム１００は主
演算処理装置または中央演算処理装置（ＣＰＵ）１０５
を含んでいる。ＣＰＵ１０５は、システム・バス１５
０を介してデータ記憶装置１４０と端末インターフェー
ス１４５に接続されている。端末インターフェース１４
５は、システム管理者やコンピュータ・プログラマやユ
ーザが、通常はプログラマブル・ワークステーションを
介して、コンピュータ・システム１００と通信できるよ
うにする。図１に示したシステムは、１つの主ＣＰＵと
１本のシステム・バスだけを含むが、本発明は、複数の
ＣＰＵと複数の入出力バスを有するコンピュータ・シス
テムにも同様に適用される。同様に、好ましい実施例の
バスは典型的ハードワイヤ式分岐バスであるが、両方向
通信をサポートする接続手段ならどんなものでも使用で
きる。

【００２５】データ記憶装置１４０は、コンピュータ・
プログラム１１０（以下、プログラムと称する）、例外
ハンドラ１１５、終了ハンドラ１１７、トラップ・ハン
ドラ１２０、ＯＳエラー・ハンドラ１２５、及びオペレ
ーティング・システム１３５を格納している。データ記
憶装置１４０は、図では単一の実体として示してある
が、図のすべてのプログラムやファイルを必ずしも１つ
の装置に格納する必要はない。たとえば、プログラム１
１０とオペレーティング・システム１３５の一部分は通
常実行のため主メモリにロードされ、原始データ・ファ
イルは、通常磁気ディスクまたは光ディスク記憶装置に
記憶される。

【００２６】図２に、呼出しのシナリオの一例を表す従
来技術のスタックを示す。スタック２００は、活動化レ
コード２０５、２１０、２１５、２２０を含んでいる。
活動化レコード２０５は、従来技術の解決策のオペレー
ティング・システムを表し、活動化レコード２１０、２
１５、２２０は、異なる３つのコンピュータ・プログラ
ムを表す。図２で、活動化レコード２１０、２１５、２
２０は、それぞれ実行可能コンピュータ・プログラム
と、その特定のコンピュータ・プログラム用の例外ハン
ドラとを指すポインタを含んでいる。プログラムＡ、
Ｂ、Ｃの言語は、それぞれＰＬ／１、ＡＤＡ、Ｃ言語で
ある。

【００２７】プログラムＡは、活動化レコード２１０で
示される。活動化レコード２１０は、スタックに最初に
置かれるので、このシナリオでは、コンピュータ・シス
テム１００上で最初に実行されたコンピュータ・プログ
ラム（すなわち、プログラムＡ）を表す。プログラムＡ
は、プログラムＢを呼び出し、したがって活動化レコー
ド２１５（すなわち、プログラムＢを表す活動化レコー
ド）がスタックの活動化レコード２１０の上に置かれ
た。この例では、プログラムＢはプログラムＣを呼び出
したので、図では活動化レコード２２０がスタック２０
０の一番上にある。

【００２８】図３に、従来技術の解決策の「デッド・ル
ーチン」の問題を例示的に示す。上述のように従来技術
の解決策では、各例外に２つのカーソルを関連付ける。
第１のタイプのカーソル、すなわちカーソル・ハンドル
は、現在例外を処理する責任を負っているコンピュータ
・プログラムを表す、スタック上の活動化レコードを指
し、第２のタイプのカーソル、すなわち再開カーソル
は、例外の処理後に実行が再開されるコンピュータ・プ
ログラムを表す、スタック上の活動化レコードを指す。
デッド・ルーチンの問題が発生するのは、例外を処理し
ているコンピュータ・プログラム（すなわち、ハンドル
・カーソルが指している例外ハンドラ）自体が例外を生
じる時である。これは、ステップ・バイ・ステップの例
で説明するのが最良である。

【００２９】図３で、プログラムＣは例外を生じる最初
のプログラムである。再開ポインタとハンドル・ポイン
タは、図３ではそれぞれＲＣ及びＨＣとして示してあ
る。このカーソルの図には、例外数と対象カーソルの相
対移動を表す数値ポインタ識別子も示してある。たとえ
ば、ＨＣ１（Ｐ１）は、位置１における例外用のハンド
ル・カーソルを表す。その場合、最初、再開カーソルと
ハンドル・カーソルはどちらも、活動化レコード２２０
［ＨＣ１（Ｐ１）及びＲＣ１（Ｐ１）］を指す。次にＯ
Ｓエラー・ハンドラを呼び出して、それがＣ言語用の適
切な例外ハンドラ（すなわち、活動化レコード２２０の
Ｃエラー・ハンドラ・ポインタが指す例外ハンドラ）を
呼び出すことができるようにする。これらのステップ
は、図に示してない。この例では、Ｃ言語例外ハンドラ
は、その例外を処理できないものとする。そうすると、
オペレーティング・システムのエラー・ハンドラに戻
り、それがハンドル・カーソルを下方へ活動化レコード
２１５の所まで移動し、そこでＡＤＡ例外ハンドラが呼
び出される［ＨＣ１（Ｐ２）]。活動化レコード２３０
は、ＡＤＡ例外ハンドラを表す。ＡＤＡ言語は、終了例
外処理モデルを使用するので、ＡＤＡ例外ハンドラは、
再開カーソルを活動化レコード２２０から下方へ活動化
レコード２１５の所まで移動する［ＲＣ１（Ｐ２）］。
この時点で、プログラムＣが「デッド・ルーチン」にな
っている。次にＡＤＡ例外ハンドラは、プログラムＣの
後を「クリーンアップ」するために（活動化レコード２
３５で表される）プログラムＤを呼び出す。

【００３０】第１の例外の場合と同様に、最初、この例
外用のハンドル・カーソルと再開カーソルも活動化レコ
ード２３５を指す［ＨＣ２（Ｐ１）及びＲＣ２（Ｐ
１）］。この場合も（活動化レコード２４０で示される
ように）問題を処理するために、ＯＳエラー・ハンドラ
が呼び出される。ＯＳエラー・ハンドラは、プログラム
Ｄに関連する例外ハンドラがないと判定すると、ハンド
ル・カーソルを下方に活動化レコード２３０の所まで移
動し、再度ＡＤＡ例外ハンドラを呼び出す［ＨＣ２（Ｐ
２）］。ＡＤＡ例外ハンドラのこの事例は、活動化レコ
ード２４５で示される。終了モデルでは、次にＡＤＡ例
外ハンドラは、プログラムＤの後にクリーンアップする
ために別のプログラムを呼び出し、再開カーソルを適当
に（すなわち、活動化レコード２３５から下方に活動化
レコード２３０の所まで）移動する［ＲＣ２（Ｐ
２）］。もちろん、これによってプログラムＤがもう１
つのデッド・ルーチンになる。問題が解決されずに続く
場合、スタックをサポートするのに使用されるメモリは
最終的に使い尽くされ、コンピュータ・システム自体が
停止することになる。

【００３１】上述のように、従来技術の解決策に伴う第
２の問題は、例外データの管理である。図３に示すよう
に、従来技術の解決策の例外データは、その特定の例外
に対して責任を負うオペレーティング・システムに対し
て局所的に保たれる。図４に従来技術の例外データ・レ
コードの例を示す。例外データ・レコード２５５は、例
外原因フィールド２６０と他の例外データ・フィールド
２６５を含んでいる。例外原因フィールド２６０は、そ
の名前が示すように、例外の原因に関する情報を格納す
る。他の例外データ・フィールド２６５は、特定の例外
ハンドラにとって重要となる可能性のある他の例外デー
タ情報を格納するために使用する。その例としては、詳
細原因コード、例外を生じたプログラムのプログラムＩ
Ｄ、例外発生時のプロセス状態、例外に関する位置情報
などがある。

【００３２】この情報は、その例外に対して責任を負う
ＯＳエラー・ハンドラの事例に対して局所的に記憶され
るので、その情報を呼出しステートメント・パラメータ
を介して、またはオペレーティング・システム自体によ
って提供されるサービス・ルーチンを経て、後の例外ハ
ンドラに渡さなければならない。これにより２つの問題
が生じる。情報が呼出しステートメント自体を介して使
用可能になる場合、その情報は、現例外ハンドラが必要
とするのに、例外の故に呼び出された介在プログラムに
よって除去されてしまっている可能性がある。同様に、
ＯＳエラー・ハンドラ自体が、最初の例外ハンドラがそ
の問題を処理するであろうと考えて、適切な情報を渡す
ことを必要と考える可能性もある。

【００３３】特別のオペレーティング・システム・サー
ビス・ルーチンでルーチン間での情報の受渡しに固有の
問題の一部が解決されるが、これらは、その特定の例外
をその例外に対して責任を負うＯＳエラー・ハンドラの
事例と関連付ける能力をもたないという欠点がある。特
定の例外ハンドラの事例が複数あるときには、これは特
に難しい問題となる。

【００３４】図５に、呼出しシナリオの例での本発明の
スタックを示す。スタック３００は、活動レコード３０
５、３１０、３１５、３２０、３２５を含んでいる。活
動化レコード３０５はオペレーティング・システム１３
５を表し、活動化レコード３１０、３１５、３２０は異
なる３つのコンピュータ・プログラムを表す。活動化レ
コード３１０、３１５、３２０はそれぞれ、図では実行
可能コンピュータ・プログラム及び制御情報ブロックを
指すポインタを含んでいる。活動化レコード３２５は、
ＯＳエラー・ハンドラ１２５を表す。

【００３５】前の例（この場合は、活動化レコード２１
０）と同様に、図では最初に活動化レコード３１０がス
タックに置かれる。したがって、活動化レコード３１０
は、この例ではコンピュータ・システム１００上で最初
に実行されたコンピュータ・プログラム（すなわち、プ
ログラムＡ）を表す。プログラムＡはプログラムＢを呼
び出し、したがって活動化レコード３１５（すなわち、
プログラムＢを表す活動化レコード）がスタックの活動
化レコード３１０の上に置かれた。この例では、プログ
ラムＢはプログラムＣを呼び出したので、活動化レコー
ド３２０が活動化レコード３１５の上にある。

【００３６】図６に、本発明の制御情報ブロックを示
す。制御情報ブロック３３０は、終了フラグ３３５、前
回障害フラグ３３７、例外原因ポインタ３４０、呼出し
メッセージ待ち行列３４５、例外ハンドラ・ポインタ３
５０、及び終了ハンドラ・ポインタ３５５を含んでい
る。これらのフィールドの意味については、後で図７な
いし図１２に詳しく説明する。

【００３７】活動化レコード３２５の存在（図５）は、
スタック３００上の他の活動化レコードによって表され
るプログラムの１つによって例外が生じたことを示す。
例外が発生すると、オペレーティング・システム１３５
がＯＳエラー・ハンドラ１２５を呼び出す。ＯＳエラー
・ハンドラ１２５は、そのリターン・アドレスを対象プ
ログラム以外のルーチンに戻るように修正することによ
り、その例外を生じたプログラムを「トラップ」する。
この異なるルーチンが、トラップ・ハンドラ１２０であ
る。さらに、ＯＳエラー・ハンドラ１２５はまた、その
例外を生じたプログラムの活動化レコードに例外原因メ
ッセージをリンクする。

【００３８】図７ないし図１２は、図１３及び図１４と
あいまって、本発明のトラップ・ハンドラ１２０及び他
の機構の内部動作を説明するのに使用される。図７に
は、ＯＳエラー・ハンドラ１２５（図５で活動化レコー
ド３２５によって表される）がその初期処理を実行した
後のスタック３００を示す。図では、スタック３００
は、先に論じた活動化レコード３０５、３１０、３１
５、３２０に加えて、トラップ・ハンドラ４２５、呼出
しメッセージ待ち行列４３０、４４０、４４５、及び例
外原因メッセージ４３５も含んでいる。

【００３９】本発明の機構は、終了例外モデルと非終了
例外モデルを平等に扱う。本発明の基本機構を、非終了
モデルのもとで動作するルーチンを使用した例によって
説明する。基本機構について考察した後、終了モデルの
もとで動作するルーチンを使用した例について述べる。
この後者の例は、本発明の機構が「デッド・ルーチン」
の問題を克服する手法をどのようにして提供するかを説
明するのに最も適している。

【００４０】非終了モデルの処理図１３及び図１４は、トラップ・ハンドラ１２０の流れ
図である。トラップ・ハンドラ１２０は呼び出される
と、ブロック５１５で、まずトラップされたルーチンが
「終了」のためにトラップされたのか、それとも「例外
のためにトラップされた」のかを判定する。トラップ・
ハンドラ１２０は、終了フラグ３３５（図６）を検査す
ることによってこの判定を行う。対象プログラムが終了
のためにトラップされていた場合、終了フラグ３３５は
論理１に設定される。これが起こるのは、終了例外モデ
ルのもとで動作するプログラム（たとえば、ＡＤＡ）が
使用されるときである。このフラグは、それ自体が終了
したいプログラムによって、または特定のプログラムを
終了させたい例外ハンドラによってセットすることがで
きる。ただし、この例では、スタック３００の諸プログ
ラムがＣ言語で書かれており、したがって非終了例外モ
デルのもとで動作するものと仮定する。その場合、終了
フラグ３３５はセットされない（すなわち、論理０の値
をとる）。

【００４１】最初にプログラムＣによって例外が通知さ
れると仮定すると、トラップ・ハンドラ１２０は先に進
んで、ブロック５２０で、プログラムＣが例外のために
トラップされているかどうか判定する。これは、プログ
ラムＣの制御情報を用いて関連する例外原因の位置決定
を試みることによって行われる。トラップ・ハンドラ１
２０は、例外原因ポインタ３４０（図６）を使って、例
外原因メッセージ４３５（図７）の位置決定を試みる。
例外原因ポインタ３４０がNullである（すなわち、有効
値をもたない）場合、トラップ・ハンドラ１２０は、対
象プログラムをもはやトラップする必要がないことを知
り、先に進んでブロック５２５でトラップをクリアし、
ブロック５８０で対象プログラムに制御を戻す。

【００４２】しかし、ここで例外原因ポインタ３４０が
有効なアドレスをもち、ブロック５３５でトラップ・ハ
ンドラ１２０が例外原因メッセージ４３５の位置決定を
行える。例外原因メッセージ４３５は、以前にＯＳエラ
ー・ハンドラ１２５によって活動化レコード３２０にリ
ンクされており、対象例外のために使用可能なすべての
情報を含んでいる。この情報には、詳細原因コード、そ
の例外を生じたプログラムのプログラムＩＤ、例外発生
時のプロセス状態、その例外に関する位置情報などが含
まれる。例外原因メッセージは、その他に、それが現在
入れられている特定の呼出しメッセージ待ち行列に関す
る位置情報も含んでいる。

【００４３】例外原因メッセージ４３５は、最初に呼出
しメッセージ待ち行列４３０に入れられる。例外原因メ
ッセージ４３５の位置決定後、ブロック５４５でトラッ
プ・ハンドラ１２０は、例外原因メッセージ４３５内に
含まれる位置情報を使って、適切な（すなわち、ターゲ
ット呼出しのための）制御情報を位置決定する。最初
に、トラップ・ハンドラ１２０は、プログラムＣに関連
する制御情報を位置決定する。このステップは、やや循
環的であるが、汎用機械の設計に必要である。

【００４４】ブロック５５５で、トラップ・ハンドラ１
２０は、この例外を処理するために特定のプログラムに
関連する例外ハンドラが既に呼び出されたかどうか（す
なわち、それが既に試みられ失敗したかどうか）を判定
する。トラップ・ハンドラ１２０は、前回失敗フラグ３
３７（図５）を検査することによってこの判定を行う。
この例外ハンドラはまだ呼び出されていないので、トラ
ップ・ハンドラ１２０は前回失敗フラグ３３７を論理１
にセットし、ブロック５６５で例外ハンドラ・ポインタ
３５０（図５）で識別されるプログラムＣに関連する例
外ハンドラを呼び出す。この例外ハンドラは、本明細書
に記載する他の例外ハンドラと同様に、コンピュータ・
システム１００上では、図１の例外ハンドラ１１５によ
って論理的に表されることを理解されたい。この説明で
は、この例外ハンドラは、この特定の例外を処理できな
いものと仮定する。この例外ハンドラは、この例外を処
理できないので、トラップ・ハンドラ１２０に制御を戻
し、ブロック５８０でトラップ・ハンドラ１２０自体も
リターンする。

【００４５】プログラムＣはトラップされたままなの
で、トラップ・ハンドラ１２０は直ちに再呼出しされ
る。前回と同様に、トラップ・ハンドラ１２０はブロッ
ク５１５で終了フラグ３３５を検査し、ブロック５２０
で例外原因メッセージ・ポインタ３４０を検査し、ブロ
ック５３５で例外原因メッセージ４３５を位置決定し、
ブロック５４５で例外原因メッセージ４３５を使ってタ
ーゲット呼出しを位置決定する。ただし、先に進んでプ
ログラムＣ用の例外ハンドラを再呼出しする代わりに、
トラップ・ハンドラ１２０は、ブロック５５５で、（前
回失敗フラグ３３７を使って）この例外ハンドラが既に
問題の解決を試みて失敗したかどうかを判定する。その
後、トラップ・ハンドラ１２０は先に進んで、例外原因
メッセージを下方にスタック上の次の呼出しの呼出しメ
ッセージ待ち行列まで移動（すなわち、パーコレート）
する。図７に示すように、例外原因メッセージ４３５
は、下方にプログラムＢと活動化レコード３１５に関連
する呼出しメッセージ待ち行列４４０まで移動されてい
る。次にブロック５８０で、トラップ・ハンドラ１２０
はリターンする。

【００４６】プログラムＣはトラップされたままなの
で、トラップ・ハンドラ１２０は再度再呼出しされる。
トラップ・ハンドラ１２０は、ブロック５１５でもう一
度終了フラグ３３５を検査し、ブロック５２０で例外原
因メッセージ・ポインタ３４０を検査し、ブロック５３
５で例外原因メッセージ４３５を位置決定し、ブロック
５４５で例外原因メッセージ４３５を使ってターゲット
呼出しを位置決定する。しかし、今度は例外原因メッセ
ージ４３５内の位置情報は、トラップ・ハンドラ１２０
を、プログラムＢに関連する制御情報（すなわち、活動
化レコード３１５）へと導く。ブロック５５５で、トラ
ップ・ハンドラ１２０は、この例外を処理するためにプ
ログラムＢに関連する例外ハンドラが既に呼び出された
かどうか（すなわち、既に試みて失敗したかどうか）を
判定する。トラップ・ハンドラ１２０は、前回失敗フラ
グ３３７（図５）を検査することによってこの判定を行
う。この例外ハンドラはまだ呼び出されていないので、
トラップ・ハンドラ１２０は前回失敗フラグ３３７をセ
ットし、図１３のブロック５６５で、例外ハンドラ・ポ
インタ３５０（図５）で識別される例外ハンドラを呼び
出す。この説明では、プログラムＢ用の例外ハンドラが
そのエラー条件を処理できるものと仮定する。そうであ
る場合、例外ハンドラは例外原因メッセージ４３５を削
除して、例外原因ポインタ３４０をクリアさせる。次に
例外ハンドラは、トラップ・ハンドラ１２０に制御を戻
し、トラップ・ハンドラ１２０はプログラムＣに制御を
戻す。ただし、この時点でプログラムＣはトラップされ
たままであり、したがって直ちにトラップ・ハンドラ１
２０に制御が戻される。次いでブロック５２０でトラッ
プ・ハンドラ１２０は、プログラムＣをもはやトラップ
する必要がないと判定し、先に進んでプログラムＣのリ
ターン・アドレスを変更してその元の値５２５に戻すこ
とにより、トラップをクリアする。これが済むと、ブロ
ック５８０でトラップ・ハンドラ１２０はプログラムＣ
に制御を戻す。

【００４７】終了モデルの処理終了モデルのもとで動作するプログラムがどのように処
理されるか理解するために、もう一度、プログラムＣが
実行中に例外を生じ、したがって前述のようにトラップ
されていると仮定する。図１０ないし図１４を参照する
と、エラーを処理するために同様にトラップ・ハンドラ
１２０が呼び出される（トラップ・ハンドラ１２０は、
図１０では活動化レコード４２５で表される）。前と同
様に、トラップ・ハンドラ１２０は、終了フラグ３３５
がセットされていず、ＯＳエラー・ハンドラ１２５が例
外原因メッセージ４３５を作成し、それを例外原因ポイ
ンタ３４０を介して活動化レコード３２０にリンクした
ことを発見する。上述のように、トラップ・ハンドラ１
２０は問題を処理するために、最終的にプログラムＣに
関連する例外ハンドラを呼び出す（図１４のブロック５
６５で、図１０に活動化レコード４５０として示す）。

【００４８】この時点で、プログラムＣ用の例外ハンド
ラがそれ自体例外を生じる。これによって、トラップ・
ハンドラ１２０の別の事例と第２の例外を処理するため
の別のプログラム（すなわち、例外ハンドラ用の例外ハ
ンドラ）が、スタック３００上に置かれる（それぞれ図
１１に活動化レコード４６０及び４６５として表す）。
後者のプログラムは、図１１にプログラムＤとして示さ
れている。

【００４９】トラップ・ハンドラ１２０のこの設計によ
り、コンピュータ・プログラムは例外データをスタック
中で下方に移動して、別の例外ハンドラによって処理さ
せるようにする例外ハンドラをコーディングできるよう
になる。したがって、プログラムＤは、トラップ・ハン
ドラ１２０によって呼び出される（図１４のブロック５
６５として示す）と、活動化レコード４５０用の終了フ
ラグ３３５をセットする他に、この例外に関連する例外
原因メッセージ（例外原因メッセージ４５２）を活動化
レコード４５０の呼出しメッセージ待ち行列から明示的
に除去し、代わりの例外原因メッセージ（例外原因メッ
セージ４８８）を別の例外ハンドラの呼出しメッセージ
待ち行列に入れることができる。ここで、この例外ハン
ドラが対象例外原因メッセージをプログラムＣの呼出し
メッセージ待ち行列に入れると仮定する（図１１参
照）。プログラムＤも、活動化レコード３２０中の初期
例外原因メッセージ・ポインタ（すなわち、例外原因メ
ッセージ４３５を指すポインタ）を新しい例外原因メッ
セージ（すなわち、例外原因メッセージ４８８）で置き
換える。

【００５０】次に例外ハンドラは、トラップ・ハンドラ
１２０に戻る。プログラムＣ用の例外ハンドラがトラッ
プされたままなので、トラップ・ハンドラ１２０が再呼
出しされる。トラップ・ハンドラ１２０は、ブロック５
１５でプログラムＣ用の例外ハンドラが終了のためにト
ラップされていると判定し、ブロック５３０でこの例外
ハンドラに関連するある終了ハンドラがあればそれを実
行し、ブロック５４０で呼出しメッセージ待ち行列をク
リアし（図１１の呼出しメッセージ待ち行列４５５）、
ブロック５５０で例外原因メッセージがまだ存在するか
どうか判定する。この場合、プログラムＣ用の例外ハン
ドラの第一の事例によって生じた例外を表す例外原因メ
ッセージは、プログラムによって明示的に除去された
（すなわち、例外原因メッセージ４５２）。したがっ
て、次にトラップ・ハンドラ１２０は、ブロック５７５
でスタック３００から呼出し（すなわち、プログラムＣ
の例外ハンドラに関連する呼出し）を除去し、ブロック
５８０でリターンする。

【００５１】トラップ・ハンドラ１２０がリターンする
とき、トラップされたままのプログラムＣに戻る。した
がって、トラップ・ハンドラ１２０がもう一度再呼出し
される。上述のように、プログラムＣ用の例外ハンドラ
が、この新しい例外（すなわち、プログラムＤによって
生成され、例外原因メッセージ４８８によって表される
代わりの例外）を処理するために、最終的に呼び出され
る。プログラムＣ用の例外ハンドラが、この例外はそれ
が処理できるものではないと直ちに認識するものと仮定
する。したがって、プログラムＣ用の例外ハンドラは、
例外原因メッセージ４８８を下方にプログラムＢまでパ
ーコレートし（すなわち、活動化レコード３１５）、プ
ログラムＣを終了することを決定する。そうするため
に、例外ハンドラは、例外原因メッセージ４８８を呼出
しメッセージ待ち行列４３０から下方に呼出しメッセー
ジ待ち行列４４０まで移動し、活動化レコード３２０用
の終了フラグ３３５をセットする。次に、例外ハンドラ
は制御をトラップ・ハンドラ１２０に戻し、ブロック５
８０でトラップ・ハンドラがリターンする。しかし、ト
ラップ・ハンドラ１２０がプログラムＣに制御を戻そう
と試みたとき、プログラムＣがトラップされたままであ
ることを発見し、したがってそれが直ちに再呼出しされ
る。

【００５２】プログラムＣ用の例外ハンドラと同様に、
トラップ・ハンドラ１２０は、ブロック５１５で終了フ
ラグ３３５がセットされたと判定し、ブロック５３０に
進んでプログラムＣ用の終了ハンドラを呼び出す。これ
は、活動化レコード３２０の制御情報ブロックの終了ハ
ンドラ・ポインタ・フィールド３５５を介して達成され
る。この終了ハンドラは、終了ハンドラ１１７の１つで
ある。対象終了ハンドラは次に先に進んでプログラムＣ
の後でクリーンアップする。このタスクには、メモリと
ロックを解放し、または他の一般的分解動作を実行し、
あるいはその両方を行うことが必要なことがある。

【００５３】対象終了ハンドラがその処理を完了する
と、トラップ・ハンドラ１２０に制御を戻す。トラップ
・ハンドラ１２０は先に進んで、ブロック５４０でプロ
グラムＣ用に定義されている呼出しメッセージ待ち行列
をクリアし、ブロック５５０でプログラムＣ用の例外原
因メッセージが作成されているかどうか検査する。この
場合、例外原因メッセージ４８８は、活動化レコード３
２０にリンクされたままとなる。したがって、ブロック
５６０でトラップ・ハンドラ１２０は、例外原因メッセ
ージ４８８を下方に活動化レコード３１５（すなわち、
プログラムＢ用の活動化レコード）に転送する。この時
点で、トラップ・ハンドラ１２０は、先に進んでブロッ
ク５７５でスタックからプログラムＣを除去し、ブロッ
ク５８０でリターンする。次いで、プログラムＢで処理
が続行し、トラップ・ハンドラ１２０が例外原因メッセ
ージ４８８によって表される例外を処理するためにプロ
グラムＢ用の例外ハンドラを呼び出す。従来技術の解決
策を使用している場合は、プログラムＢ用の例外ハンド
ラが強制的にこの第２の例外を処理してからでないと、
デッド・ルーチン（プログラムＣ、プログラムＣ用の例
外ハンドラ、及び恐らくはプログラムＤ）をスタックか
ら除去できないことになる。こうなるのは、従来技術の
解決策では、すべての例外データを、例外の処理を開始
するＯＳエラー・ハンドラにとって局所的に保つからで
ある（図３及び関連する本文を参照のこと）。しかし、
本発明の例外データは、走行中のどのプログラムにとっ
ても外部にあり、したがって走行中のすべてのプログラ
ムにとって使用可能である。

【００５４】この時点で、処理は上述のように続行す
る。図１２に示すようにデッド・ルーチン（プログラム
Ｃ）は、除去されている。第２の例外（すなわち、例外
原因メッセージ４８８によって表される例外）は、通常
の手順で処理される。

【００５５】外部化された例外データ「発明が解決しようとする課題」及び「課題を解決する
ための手段」の所で考察したように、本発明は従来技術
の例外データ管理の問題をも解決する。制御情報ブロッ
クのポインタ（図８）を介して、例外データが「外部
化」されており、したがって情報を必要とするプロセス
は、渡された変数や特別のシステム・コールに依存する
必要なく、その情報にアクセスすることができる。さら
に、例外データは、その例外を処理する責任を最終的に
負うルーチンの活動化レコードに直接結合されるので、
どの例外データがどの位置に記憶されるかについて混乱
はない。

【００５６】本発明に関連して以下の事項について開示
する。（１）スタック中の項目である活動化レコードによって
識別される走行中のプログラム内の例外条件を検出する
ステップと、エラー・ハンドラを呼び出すステップと、
前記エラー・ハンドラによって、前記走行中のプログラ
ムをトラップするステップと、前記エラー・ハンドラに
よって、例外原因メッセージを作成するステップと、前
記エラー・ハンドラによって、前記例外原因メッセージ
を前記活動化レコードにリンクするステップと、前記エ
ラー・ハンドラによって、前記例外原因メッセージを前
記活動化レコード中で参照されるメッセージ待ち行列に
入れるステップと、前記活動化レコードに含まれるポイ
ンタを介して例外ハンドラを呼び出すステップと、を含
む、コンピュータ・システム内で例外条件を処理する方
法。（２）ａ）複数の活動化レコードを含み前記複数の活動
化レコードの１つが現活動化レコードである、タック・
フレーム内で識別され、最初に前記現活動化レコードで
ある走行中のプログラムを表す第１の活動化レコードを
有する、第１のプログラム内の例外条件を検出するステ
ップと、ｂ）エラー・ハンドラを呼び出すステップと、ｃ）前記エラー・ハンドラによって、前記第１プログラ
ムをトラップするステップと、ｄ）前記エラー・ハンドラによって、例外原因メッセー
ジを作成するステップと、ｅ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードにリンクするステップ
と、ｆ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードに含まれる第１メッセ
ージ待ち行列に入れるステップと、ｇ）前記現活動化レコード内のポインタ・フィールドを
検査することによって、前記第１プログラムがそれに関
連する例外ハンドラを有するかどうかを判定するステッ
プと、ｈ）前記判定ステップで、前記現活動化レコードに関連
する例外ハンドラがないことが示されたとき、前記第１
メッセージ待ち行列から前記例外原因メッセージを除去
し、前記例外原因メッセージを、第２プログラムに関連
し前記現活動化レコードになる第２活動化レコードに含
まれる、第２メッセージ待ち行列に入れるステップと、ｉ）前記ポインタ・フィールドが、前記現活動化レコー
ドにある例外ハンドラが関連することを示すまで、ステ
ップｇ）及びｈ）を繰り返すステップと、ｊ）前記例外ハンドラを呼び出すステップと、を含む、
コンピュータ・システム内で例外条件を処理する方法。（３）スタック中の項目である活動化レコードによって
識別される走行中のプログラム内の例外条件を検出する
ステップと、エラー・ハンドラを呼び出すステップと、
前記エラー・ハンドラによって、前記走行中のプログラ
ムをトラップするステップと、前記エラー・ハンドラに
よって、例外原因メッセージを作成するステップと、前
記エラー・ハンドラによって、前記例外原因メッセージ
を前記活動化レコードにリンクするステップと、前記エ
ラー・ハンドラによって、前記例外原因メッセージを前
記活動化レコード中で参照されるメッセージ待ち行列に
入れるステップと、前記活動化レコードに含まれるポイ
ンタを介して例外ハンドラを呼び出すステップと、前記
走行中のプログラムを終了すべきことを指示するよう
に、前記活動化レコードにマークを付けるステップと、
前記活動化レコードを前記スタックから除去することに
よって、前記走行中のプログラムを終了するステップ
と、を含む、コンピュータ・システム内で例外条件を処
理する方法。（４）ａ）複数の活動化レコードを含み前記複数の活動
化レコードの１つが現活動化レコードである、スタック
・フレーム内で識別され、最初に前記現活動化レコード
である走行中のプログラムを表す第１の活動化レコード
を有する、第１のプログラム内の例外条件を検出するス
テップと、ｂ）エラー・ハンドラを呼び出すステップと、ｃ）前記エラー・ハンドラによって、前記第１プログラ
ムをトラップするステップと、ｄ）前記エラー・ハンドラによって、例外原因メッセー
ジを作成するステップと、ｅ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードにリンクするステップ
と、ｆ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードに含まれる第１メッセ
ージ待ち行列に入れるステップと、ｇ）前記現活動化レコード内のポインタ・フィールドを
検査することによって、前記第１プログラムがそれに関
連する例外ハンドラを有するかどうかを判定するステッ
プと、ｈ）前記判定ステップで、前記現活動化レコードに関連
する例外ハンドラがないことが示されたとき、前記第１
メッセージ待ち行列から前記例外原因メッセージを除去
し、前記例外原因メッセージを、第２プログラムに関連
し前記現活動化レコードになる第２活動化レコードに含
まれる、第２メッセージ待ち行列に入れるステップと、ｉ）前記ポインタ・フィールドが、前記現活動化レコー
ドにある例外ハンドラが関連することを示すまで、ステ
ップｇ）及びｈ）を繰り返すステップと、ｊ）前記例外ハンドラを呼び出すステップと、ｋ）前記走行中のプログラムを終了すべきことを指示す
るように、前記活動化レコードにマークを付けるステッ
プと、ｌ）前記現活動化レコードを前記スタックから除去する
ことによって、前記走行中のプログラムを終了するステ
ップと、を含む、コンピュータ・システム内で例外条件
を処理する方法。（５）スタック中の項目である活動化レコードによって
識別される走行中のプログラム内の例外条件を検出する
手段と、エラー・ハンドラを呼び出す手段と、前記エラ
ー・ハンドラによって、前記走行中のプログラムをトラ
ップする手段と、前記エラー・ハンドラによって、例外
原因メッセージを作成する手段と、前記エラー・ハンド
ラによって、前記例外原因メッセージを前記活動化レコ
ードにリンクする手段と、前記エラー・ハンドラによっ
て、前記例外原因メッセージを前記活動化レコード中で
参照されるメッセージ待ち行列に入れる手段と、前記活
動化レコードに含まれるポインタを介して例外ハンドラ
を呼び出す手段と、を含む、コンピュータ・システム内
で例外条件を処理するための装置。（６）ａ）複数の活動化レコードを含み前記複数の活動
化レコードの１つが現活動化レコードである、スタック
・フレーム内で識別され、最初に前記現活動化レコード
である走行中のプログラムを表す第１の活動化レコード
を有する、第１のプログラム内の例外条件を検出する手
段と、ｂ）エラー・ハンドラを呼び出す手段と、ｃ）前記エラー・ハンドラによって、前記第１プログラ
ムをトラップする手段と、ｄ）前記エラー・ハンドラによって、例外原因メッセー
ジを作成する手段と、ｅ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードにリンクする手段と、ｆ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードに含まれる第１メッセ
ージ待ち行列に入れる手段と、ｇ）前記現活動化レコード内のポインタ・フィールドを
検査することによって、前記第１プログラムがそれに関
連する例外ハンドラを有するかどうかを判定する手段
と、ｈ）前記判定ステップで、前記現活動化レコードに関連
する例外ハンドラがないことが示されたとき、前記第１
メッセージ待ち行列から前記例外原因メッセージを除去
し、前記例外原因メッセージを、第２プログラムに関連
し前記現活動化レコードになる第２活動化レコードに含
まれる、第２メッセージ待ち行列に入れる手段と、ｉ）前記ポインタ・フィールドが、前記現活動化レコー
ドにある例外ハンドラが関連することを示すまで、前記
判定手段及び前記除去手段を繰り返す手段と、ｊ）前記例外ハンドラを呼び出す手段と、を含む、コン
ピュータ・システム内で例外条件を処理するための装
置。（７）スタック中の項目である活動化レコードによって
識別される走行中のプログラム内の例外条件を検出する
手段と、エラー・ハンドラを呼び出す手段と、前記エラ
ー・ハンドラによって、前記走行中のプログラムをトラ
ップする手段と、前記エラー・ハンドラによって、例外
原因メッセージを作成する手段と、前記エラー・ハンド
ラによって、前記例外原因メッセージを前記活動化レコ
ードにリンクする手段と、前記エラー・ハンドラによっ
て、前記例外原因メッセージを前記活動化レコード中で
参照されるメッセージ待ち行列に入れる手段と、前記活
動化レコードに含まれるポインタを介して例外ハンドラ
を呼び出す手段と、前記走行中のプログラムを終了すべ
きことを指示するように、前記活動化レコードにマーク
を付ける手段と、前記活動化レコードを前記スタックか
ら除去することによって、前記走行中のプログラムを終
了する手段と、を含む、コンピュータ・システム内で例
外条件を処理するための装置。（８）ａ）複数の活動化レコードを含み前記複数の活動
化レコードの１つが現活動化レコードである、スタック
・フレーム内で識別され、最初に前記現活動化レコード
である走行中のプログラムを表す第１の活動化レコード
を有する、第１のプログラム内の例外条件を検出する手
段と、ｂ）エラー・ハンドラを呼び出す手段と、ｃ）前記エラー・ハンドラによって、前記第１プログラ
ムをトラップする手段と、ｄ）前記エラー・ハンドラによって、例外原因メッセー
ジを作成する手段と、ｅ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードにリンクする手段と、ｆ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードに含まれる第１メッセ
ージ待ち行列に入れる手段と、ｇ）前記現活動化レコード内のポインタ・フィールドを
検査することによって、前記第１プログラムがそれに関
連する例外ハンドラを有するかどうかを判定する手段
と、ｈ）前記判定ステップで、前記現活動化レコードに関連
する例外ハンドラがないことが示されたとき、前記第１
メッセージ待ち行列から前記例外原因メッセージを除去
し、前記例外原因メッセージを、第２プログラムに関連
し前記現活動化レコードになる第２活動化レコードに含
まれる、第２メッセージ待ち行列に入れる手段と、ｉ）前記ポインタ・フィールドが、前記現活動化レコー
ドにある例外ハンドラが関連することを示すまで、前記
判定手段及び前記除去手段を繰り返す手段と、ｊ）前記例外ハンドラを呼び出す手段と、ｋ）前記走行中のプログラムを終了すべきことを指示す
るように、前記活動化レコードにマークを付ける手段
と、ｌ）前記現活動化レコードを前記スタックから除去する
ことによって、前記走行中のプログラムを終了する手段
と、を含む、コンピュータ・システム内で例外条件を処
理するための装置。

【図面の簡単な説明】

【図１】好ましい実施例のコンピュータ・システムを示
す図である。

【図２】従来技術のコール／リターン・スタックを示す
図である。

【図３】例外が生じた従来技術のコール／リターン・ス
タックを示す図である。

【図４】従来技術の例外データ・レコードを示す図であ
る。

【図５】本発明のコール／リターン・スタックの構造を
示す図である。

【図６】本発明の制御情報レコードの構造を示す図であ
る。

【図７】本発明によって例外がどのように処理されるか
を示す、コール／リターン・スタッフの例を示す図であ
る。

【図８】本発明によって例外がどのように処理されるか
を示す、コール／リターン・スタッフの例を示す図であ
る。

【図９】本発明によって例外がどのように処理されるか
を示す、コール／リターン・スタッフの例を示す図であ
る。

【図１０】本発明によって例外がどのように処理される
かを示す、コール／リターン・スタッフの例を示す図で
ある。

【図１１】本発明によって例外がどのように処理される
かを示す、コール／リターン・スタッフの例を示す図で
ある。

【図１２】本発明によって例外がどのように処理される
かを示す、コール／リターン・スタッフの例を示す図で
ある。

【図１３】本発明によって例外がどのように処理される
かを示す、トラップ・ハンドラの流れ図である。

【図１４】本発明によって例外がどのように処理される
かを示す、トラップ・ハンドラの流れ図である。

【符号の説明】

１００コンピュータ・システム１０５中央演算処理装置（ＣＰＵ）１１０コンピュータ・プログラム１１５例外ハンドラ１１７終了ハンドラ１２０トラップ・ハンドラ１２５ＯＳエラー・ハンドラ１３５オペレーティング・システム１４０データ記憶装置１４５端末インターフェース１５０システム・バス

───────────────────────────────────────────────────── フロントページの続き (72)発明者ダニエル・ロッドマン・ヒックスアメリカ合衆国55920 ミネソタ州バイロンフォース・アベニューノース・イースト513

Claims

【特許請求の範囲】

【請求項１】スタック中の項目である活動化レコードに
よって識別される走行中のプログラム内の例外条件を検
出するステップと、エラー・ハンドラを呼び出すステップと、前記エラー・ハンドラによって、前記走行中のプログラ
ムをトラップするステップと、前記エラー・ハンドラによって、例外原因メッセージを
作成するステップと、前記エラー・ハンドラによって、前記例外原因メッセー
ジを前記活動化レコードにリンクするステップと、前記エラー・ハンドラによって、前記例外原因メッセー
ジを前記活動化レコード中で参照されるメッセージ待ち
行列に入れるステップと、前記活動化レコードに含まれるポインタを介して例外ハ
ンドラを呼び出すステップと、を含む、コンピュータ・システム内で例外条件を処理す
る方法。
【請求項２】ａ）複数の活動化レコードを含み前記複数
の活動化レコードの１つが現活動化レコードである、タ
ック・フレーム内で識別され、最初に前記現活動化レコ
ードである走行中のプログラムを表す第１の活動化レコ
ードを有する、第１のプログラム内の例外条件を検出す
るステップと、ｂ）エラー・ハンドラを呼び出すステップと、ｃ）前記エラー・ハンドラによって、前記第１プログラ
ムをトラップするステップと、ｄ）前記エラー・ハンドラによって、例外原因メッセー
ジを作成するステップと、ｅ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードにリンクするステップ
と、ｆ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードに含まれる第１メッセ
ージ待ち行列に入れるステップと、ｇ）前記現活動化レコード内のポインタ・フィールドを
検査することによって、前記第１プログラムがそれに関
連する例外ハンドラを有するかどうかを判定するステッ
プと、ｈ）前記判定ステップで、前記現活動化レコードに関連
する例外ハンドラがないことが示されたとき、前記第１
メッセージ待ち行列から前記例外原因メッセージを除去
し、前記例外原因メッセージを、第２プログラムに関連
し前記現活動化レコードになる第２活動化レコードに含
まれる、第２メッセージ待ち行列に入れるステップと、ｉ）前記ポインタ・フィールドが、前記現活動化レコー
ドにある例外ハンドラが関連することを示すまで、ステ
ップｇ）及びｈ）を繰り返すステップと、ｊ）前記例外ハンドラを呼び出すステップと、を含む、コンピュータ・システム内で例外条件を処理す
る方法。
【請求項３】スタック中の項目である活動化レコードに
よって識別される走行中のプログラム内の例外条件を検
出するステップと、エラー・ハンドラを呼び出すステップと、前記エラー・ハンドラによって、前記走行中のプログラ
ムをトラップするステップと、前記エラー・ハンドラによって、例外原因メッセージを
作成するステップと、前記エラー・ハンドラによって、前記例外原因メッセー
ジを前記活動化レコードにリンクするステップと、前記エラー・ハンドラによって、前記例外原因メッセー
ジを前記活動化レコード中で参照されるメッセージ待ち
行列に入れるステップと、前記活動化レコードに含まれるポインタを介して例外ハ
ンドラを呼び出すステップと、前記走行中のプログラムを終了すべきことを指示するよ
うに、前記活動化レコードにマークを付けるステップ
と、前記活動化レコードを前記スタックから除去することに
よって、前記走行中のプログラムを終了するステップ
と、を含む、コンピュータ・システム内で例外条件を処理す
る方法。
【請求項４】ａ）複数の活動化レコードを含み前記複数
の活動化レコードの１つが現活動化レコードである、ス
タック・フレーム内で識別され、最初に前記現活動化レ
コードである走行中のプログラムを表す第１の活動化レ
コードを有する、第１のプログラム内の例外条件を検出
するステップと、ｂ）エラー・ハンドラを呼び出すステップと、ｃ）前記エラー・ハンドラによって、前記第１プログラ
ムをトラップするステップと、ｄ）前記エラー・ハンドラによって、例外原因メッセー
ジを作成するステップと、ｅ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードにリンクするステップ
と、ｆ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードに含まれる第１メッセ
ージ待ち行列に入れるステップと、ｇ）前記現活動化レコード内のポインタ・フィールドを
検査することによって、前記第１プログラムがそれに関
連する例外ハンドラを有するかどうかを判定するステッ
プと、ｈ）前記判定ステップで、前記現活動化レコードに関連
する例外ハンドラがないことが示されたとき、前記第１
メッセージ待ち行列から前記例外原因メッセージを除去
し、前記例外原因メッセージを、第２プログラムに関連
し前記現活動化レコードになる第２活動化レコードに含
まれる、第２メッセージ待ち行列に入れるステップと、ｉ）前記ポインタ・フィールドが、前記現活動化レコー
ドにある例外ハンドラが関連することを示すまで、ステ
ップｇ）及びｈ）を繰り返すステップと、ｊ）前記例外ハンドラを呼び出すステップと、ｋ）前記走行中のプログラムを終了すべきことを指示す
るように、前記活動化レコードにマークを付けるステッ
プと、ｌ）前記現活動化レコードを前記スタックから除去する
ことによって、前記走行中のプログラムを終了するステ
ップと、を含む、コンピュータ・システム内で例外条件を処理す
る方法。
【請求項５】スタック中の項目である活動化レコードに
よって識別される走行中のプログラム内の例外条件を検
出する手段と、エラー・ハンドラを呼び出す手段と、前記エラー・ハンドラによって、前記走行中のプログラ
ムをトラップする手段と、前記エラー・ハンドラによって、例外原因メッセージを
作成する手段と、前記エラー・ハンドラによって、前記例外原因メッセー
ジを前記活動化レコードにリンクする手段と、前記エラー・ハンドラによって、前記例外原因メッセー
ジを前記活動化レコード中で参照されるメッセージ待ち
行列に入れる手段と、前記活動化レコードに含まれるポインタを介して例外ハ
ンドラを呼び出す手段と、を含む、コンピュータ・システム内で例外条件を処理す
るための装置。
【請求項６】ａ）複数の活動化レコードを含み前記複数
の活動化レコードの１つが現活動化レコードである、ス
タック・フレーム内で識別され、最初に前記現活動化レ
コードである走行中のプログラムを表す第１の活動化レ
コードを有する、第１のプログラム内の例外条件を検出
する手段と、ｂ）エラー・ハンドラを呼び出す手段と、ｃ）前記エラー・ハンドラによって、前記第１プログラ
ムをトラップする手段と、ｄ）前記エラー・ハンドラによって、例外原因メッセー
ジを作成する手段と、ｅ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードにリンクする手段と、ｆ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードに含まれる第１メッセ
ージ待ち行列に入れる手段と、ｇ）前記現活動化レコード内のポインタ・フィールドを
検査することによって、前記第１プログラムがそれに関
連する例外ハンドラを有するかどうかを判定する手段
と、ｈ）前記判定ステップで、前記現活動化レコードに関連
する例外ハンドラがないことが示されたとき、前記第１
メッセージ待ち行列から前記例外原因メッセージを除去
し、前記例外原因メッセージを、第２プログラムに関連
し前記現活動化レコードになる第２活動化レコードに含
まれる、第２メッセージ待ち行列に入れる手段と、ｉ）前記ポインタ・フィールドが、前記現活動化レコー
ドにある例外ハンドラが関連することを示すまで、前記
判定手段及び前記除去手段を繰り返す手段と、ｊ）前記例外ハンドラを呼び出す手段と、を含む、コンピュータ・システム内で例外条件を処理す
るための装置。
【請求項７】スタック中の項目である活動化レコードに
よって識別される走行中のプログラム内の例外条件を検
出する手段と、エラー・ハンドラを呼び出す手段と、前記エラー・ハンドラによって、前記走行中のプログラ
ムをトラップする手段と、前記エラー・ハンドラによって、例外原因メッセージを
作成する手段と、前記エラー・ハンドラによって、前記例外原因メッセー
ジを前記活動化レコードにリンクする手段と、前記エラー・ハンドラによって、前記例外原因メッセー
ジを前記活動化レコード中で参照されるメッセージ待ち
行列に入れる手段と、前記活動化レコードに含まれるポインタを介して例外ハ
ンドラを呼び出す手段と、前記走行中のプログラムを終了すべきことを指示するよ
うに、前記活動化レコードにマークを付ける手段と、前記活動化レコードを前記スタックから除去することに
よって、前記走行中のプログラムを終了する手段と、を含む、コンピュータ・システム内で例外条件を処理す
るための装置。
【請求項８】ａ）複数の活動化レコードを含み前記複数
の活動化レコードの１つが現活動化レコードである、ス
タック・フレーム内で識別され、最初に前記現活動化レ
コードである走行中のプログラムを表す第１の活動化レ
コードを有する、第１のプログラム内の例外条件を検出
する手段と、ｂ）エラー・ハンドラを呼び出す手段と、ｃ）前記エラー・ハンドラによって、前記第１プログラ
ムをトラップする手段と、ｄ）前記エラー・ハンドラによって、例外原因メッセー
ジを作成する手段と、ｅ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードにリンクする手段と、ｆ）前記エラー・ハンドラによって、前記例外原因メッ
セージを前記第１活動化レコードに含まれる第１メッセ
ージ待ち行列に入れる手段と、ｇ）前記現活動化レコード内のポインタ・フィールドを
検査することによって、前記第１プログラムがそれに関
連する例外ハンドラを有するかどうかを判定する手段
と、ｈ）前記判定ステップで、前記現活動化レコードに関連
する例外ハンドラがないことが示されたとき、前記第１
メッセージ待ち行列から前記例外原因メッセージを除去
し、前記例外原因メッセージを、第２プログラムに関連
し前記現活動化レコードになる第２活動化レコードに含
まれる、第２メッセージ待ち行列に入れる手段と、ｉ）前記ポインタ・フィールドが、前記現活動化レコー
ドにある例外ハンドラが関連することを示すまで、前記
判定手段及び前記除去手段を繰り返す手段と、ｊ）前記例外ハンドラを呼び出す手段と、ｋ）前記走行中のプログラムを終了すべきことを指示す
るように、前記活動化レコードにマークを付ける手段
と、ｌ）前記現活動化レコードを前記スタックから除去する
ことによって、前記走行中のプログラムを終了する手段
と、を含む、コンピュータ・システム内で例外条件を処理す
るための装置。