(57)【要約】【課題】  ルーチン間における例外処理の一貫性や連携の欠如により、例外捕捉の漏洩やプログラムの開発生産性の低下を招くという不都合を解決すること。【解決手段】  例外処理をルーチン単位で行なう。その場合、例外検査範囲をルーチンの全手続き部分とし、かつ、全ての型の例外情報を捕捉する。そしてプログラム中で使用するルーチンは全て（または、少なくともユーザー定義部分のみは）その条件を満たす。例外が発生した場合は、通常の処理を中止して、必要な後処理を行なった後、上位ルーチンへ制御を戻す。その時、必要に応じて上位ルーチンへ例外情報を投入する。【選択図】  図３
2006127440.tif 000002
【特許請求の範囲】
【請求項１】
複数のルーチン間を適宜移行しながら一連の処理を行うように記述されたプログラムの実行時に例外が発生した場合の例外処理方法であって、そのプログラムを構成するユーザー定義ルーチンの全てが、プロセッサが行う処理手続き部の全範囲で、メモリ上に存在する全データ型の例外情報の発生の有無を検査し、例外情報の発生時にプロセッサが行う処理手続き中でルーチン毎に必要な後処理手続きを行なった後、呼び出し元へプロセッサの制御を戻すことを特徴とする例外処理方法。
【請求項２】
上記プログラムを構成するルーチンの全てが、プロセッサが行う処理手続き部の全範囲で、メモリ上に存在する全データ型の例外情報の発生の有無を検査し、例外情報の発生時にプロセッサが行う処理手続き中でルーチン毎に必要な後処理手続きを行なった後、呼び出し元へプロセッサの制御を戻すことを特徴とする例外処理方法。
【請求項３】
上記プログラムを構成するユーザー定義ルーチン全てが、上記例外情報発生時にプロセッサが行う処理手続き中に、例外の判別に用いる情報をメモリ上に確保する処理手続き、その情報を種々の表示装置や記憶装置に出力する処理手続き、その情報を例外情報として呼び出し元に投入しつつプロセッサの制御を戻す処理手続き、その例外情報を種々の表示装置や記憶装置に出力する処理手続きの何れか１つ以上を含むことによる例外判別機能を有することを特徴とする請求項１または２に記載の例外処理方法。
【請求項４】
上記プログラムを構成するルーチンの全てが、上記例外情報発生時にプロセッサが行う処理手続き中に、例外の判別に用いる情報をメモリ上に確保する処理手続き、その情報を種々の表示装置や記憶装置に出力する処理手続き、その情報を例外情報として呼び出し元に投入しつつプロセッサの制御を戻す処理手続き、その例外情報を種々の表示装置や記憶装置に出力する処理手続きの何れか１つ以上を含むことによる例外判別機能を有することを特徴とする請求項１または２に記載の例外処理方法。
【請求項５】
上記プログラムを構成するユーザー定義ルーチン全てに関して、上記例外情報発生時にプロセッサが行う請求項３に記載の例外判別のための処理手続きをコンパイラ又はアセンブラに対する制御指令によって選択的に決定して例外判別機能の統一をとり、その後実行ファイル形式に変換することにより例外判別機能を有することを特徴とする請求項１または２に記載の例外処理方法。
【請求項６】
上記プログラムを構成するルーチン全てに関して、上記例外情報発生時にプロセッサが行う請求項４に記載の例外判別のための処理手続きをコンパイラ又はアセンブラに対する制御指令によって選択的に決定して例外判別機能の統一をとり、その後実行ファイル形式に変換することにより例外判別機能を有することを特徴とする請求項１または２に記載の例外処理方法。
【請求項７】
上記プログラムを構成するユーザー定義ルーチンの全てを記述するプログラミング言語を、Ｃ＋＋言語とすることを特徴とする請求項１〜６に記載の例外処理方法。
【請求項８】
請求項１〜７の何れか１項に記載の例外処理方法の処理手続きをコンピュータに実行させるためのコンピュータ読み取り可能なプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、コンピュータ・ソフトウェアの例外処理方法、特に複数のルーチン間を適宜移行しながら一連の処理を行うように記述されたプログラムの実行時に例外が発生した場合の例外処理方法に用いて好適なものである。
【背景技術】
【０００２】  現在、プログラム開発は、例えばアセンブリ言語、Ｃ，Ｃ＋＋などのコンピュータ言語によってソースコードを記述し、そのソースコードをアセンブル又は、コンパイルすることでＣＰＵが実行可能な形式の実行ファイルに加工するのが一般的である。このようにして生成されるプログラムの殆どは、メインルーチン及びサブルーチンを含む複数のルーチンプログラムの組み合わせから構成されている。【０００３】  この種のプログラムは、複数のルーチン間を適宜移行しながら一連の処理を行うようになっている。ところが、その一連の処理の途中でエラーが発生し、ルーチン内のそれ以降の処理手続きを行うことに支障を生じることがある。このような場合には、プログラムの記述に従って例外処理が実行される。【０００４】  Ｃ＋＋などで記述されるプログラムでは、エラーが発生した場合、ユーザー自身のプログラム定義によって、例外情報を生成し、例外を発生させることができる。このように一般に、例外情報を生成し、例外を発生させることを、「例外（または例外情報）を投入（または送出）する」と言う。また、プログラム内で使用する関数や演算子などのサブルーチンが例外を投入することもある。例外処理とは、そのように例外が投入された場合、それ以降の処理を打ち切って例外情報を捕捉するハンドラ（これを例外ハンドラという）内で、発生した例外を適切に処理することを言う。【０００５】  そして、例えば、現在広く普及している、いわゆるＣ＋＋系言語では、例外の発生の有無を検査する範囲を”ｔｒｙ”句で範囲指定する。また、それに対応した例外ハンドラは、それに引き続いて記述された”ｃａｔｃｈ”ブロック内で記述する。
【発明の開示】
【発明が解決しようとする課題】
【０００６】  しかし、従来、例外処理は各企業、各プログラマの裁量により、部分的に行われているに過ぎず、全てのルーチン間で一貫性を保ち、連携をとるという発想はなかった。そのような例外処理に関する一貫性の欠如は種々の不都合を招く。【０００７】  まず、例外情報捕捉の漏洩が発生し、プログラムが強制終了してしまうという危険がある。また、そのような漏洩は、当該ルーチンを終了する前に、当該ルーチンで行うべき後処理手続きを行うことなく終了もしくはリターンしてしまうという事態をもたらし、結果としてプログラムの安定性を著しく低下させたり、更には他のプログラムの実行に支障をきたしてしまう場合さえある。ここで言う「後処理手続き」とは、例えば、当該ルーチン内で動的に確保されたコンピュータ資源（例えばメモリ領域やファイルなど）の開放や、当該ルーチン内で動的に接続された通信回線の切断に関わる処理などが考えられる。【０００８】  また、そのような一貫性のない例外処理は、ルーチン間での例外処理の連携に、常に個別対応的な注意を払わねばならず、ルーチンの汎用性や再利用性を大きく損なう。それがひいては、プログラミング作業に於ける大きな負担となり、プログラミングの開発生産性やメンテナンス性に少なからぬ影響を及ぼすことになる。
【課題を解決するための手段】
【０００９】  例外処理を敷衍することにより解決する。具体的には下記（１）〜（３）の要件を満たしたルーチンのみの組み合わせにより、プログラムを構築する。請求項１においては、ユーザー定義ルーチンのみをその要件の対象とし、演算子やライブラリ関数等の実装に依存するルーチンについては、必ずしも下記（１）〜（３）の要件を満たすことを要求しないが、請求項２においては、実装に依存するルーチンを含む全てのルーチンに、下記（１）〜（３）の要件を満たすことを要求する。【００１０】  （１）例外の検査範囲は、各ルーチンの全ての手続き部分（例外ハンドラ部も含む）とする。【００１１】  （２）全てのデータ型の例外情報を検査対象とする。【００１２】  （３）例外が発生した場合は、通常の処理を中止して、例外ハンドラにプロセッサの制御を移す。例外ハンドラは当該ルーチンの必要とする後処理手続き等を行なった後、上位ルーチンへプロセッサの制御を戻す。そのリターンの方法は次の３通りである。
▲１▼新たにメモリ上に例外情報を確保し投入する
▲２▼下位ルーチンからのメモリ上の例外情報をそのまま再投入する
▲３▼例外情報を投入しない
【発明の効果】
【００１３】  一貫性があり、ルーチン間で連携がとれている例外処理が可能になった。それにより、次のような効果を期待できる。【００１４】  （１）全ルーチンで全ての例外情報を捕捉するので、例外情報捕捉の漏洩による自動的な強制終了がなくなる。【００１５】  （２）例外処理に関するルーチン間の連携を過度に気にすることなく、各ルーチンをあたかも部品のごとく再利用することが容易になる。そして、例えば、ルーチン内に，例外を送出するルーチンを追加するようなメンテナンスもまた同様に容易になる。【００１６】  （３）例外が発生したルーチンがかなり深い階層であっても、メインルーチンから例外が発生したルーチンに至るまでの全てのルーチンについて、ルーチン毎に必要な後処理手続きを完了して，メインルーチンまたはＯＳまでプロセッサの制御が戻り得ることを示している。従って例外ハンドラ部で行う後処理手続き内で、例えば当該ルーチン内で動的に確保したコンピュータ資源を開放する処理を行うならば、全てのルーチンの全ての資源を確実に解放し得ることを意味している。【００１７】  （４）例外ハンドラ部で、適切な情報を含んだ例外情報を投入したり、またそのような例外情報を表示装置や種々の記憶装置（例えばメモリやハードディスクなど）へ出力することにより例外発生箇所を特定する作業が容易になる。
【発明を実施するための最良の形態】
【００１８】  以下、本発明の実施の形態を図面に基づいて説明する。【００１９】  図１は、本実施形態のプロセッサ適用したコンピュータの構成例を示すブロック図である。【００２０】  図１において、プロセッサ１はコンピュータの全体を制御するものであり、本実施形態のプログラムを実行する。このプロセッサ１は、本発明の例外処理手段としてコンピュータを機能させるものである。【００２１】  メモリ２は、プロセッサ１が行う処理の過程で得られるデータや、処理の結果得られるデータを一時的に格納する。プロセッサ１がプログラムを実行する際には、まずメモリ２上に必要な容量の領域を割り当て、これによって確保したメモリ領域を使って処理を実行する。そして、処理の終了後には、最初に確保したメモリ領域を開放する。【００２２】  ディスプレイコントローラ３はプロセッサ１から与えられる表示命令に従って、各種情報をディスプレイ５に表示するための制御を実行する。例えば、ディスプレイコントローラ３は、プロセッサ１による処理の実行結果をディスプレイ５に表示する。また、プロセッサ１による処理の途中で例外が発生し、例外ハンドラ中にエラー情報の表示命令がある場合には、ディスプレイコントローラ３はプロセッサ１から出力された所定のエラー情報をディスプレイ５に表示する。【００２３】  ＨＤＤコントローラ４は、プロセッサ１から与えられる制御命令に従って、ハードディスク（ＨＤＤ）６に対するデータの読み書きを制御する。本実施形態のプログラムは、このハードディスク６に格納されている。また、このプログラムが開いて使用する種々のファイルも、ハードディスク６に格納されている。プロセッサ１は、ＨＤＤコントローラ４を制御してハードディスク６からプログラムの命令文を適宜読み出し、メモリ２上に展開して、メモリ２上に確保した領域をワークメモリとして使用しながら所定の処理を実行する。その際、必要であればハードディスク６からファイルを読み出し、これを開いて使用する。【００２４】  このハードディスク６に格納されているプログラムは、本発明のプログラムを構成する。このプログラムを記録する記録媒体としては、ハードディスク６以外に、ＲＯＭ，ＣＤ−ＲＯＭ，フレキシブルディスク、磁気テープ、光ディスク、光磁気ディスク、ＤＶＤ，不揮発性メモリカード等を用いることができる。また、インターネット等のネットワークを介してコンピュータにプログラムをダウンロードするようにしても良い。【００２５】  次に図２を用いて本実施形態のプログラムを構成する各ルーチンの動作を説明する。図２は、本実施形態のプログラムを構成する各ルーチンの内部構造である。【００２６】  図２において、ルーチンの処理が開始すると、まずプロセッサ１は命令を逐次実行してゆく（Ｓ１のＰ１やＰ２）が、その途中で例外情報が発生したか否かを判定する（Ｓ１のＪ１）。判定すべき例外情報の型は、全てのデータ型（ｉｎｔ型やｃｈａｒ型などの基本データ型のみならず、クラスや構造体などの独自のデータ型も含む）が対象であるが、必要に応じて、ある特定の型に対してのみ、独自の処理を施すことも可能である。【００２７】  例外情報が発生していない場合は、そのルーチンの処理を通常通り実行���る（Ｓ１のＰ１）。そしてその通常の処理が終了すると、プロセッサ１は、そのルーチンに必要な後処理手続きを実行する（Ｓ１のＰ２）。ここで言う後処理手続きとは、例えば、当該ルーチン内で動的に確保されたコンピュータ資源（例えばメモリ２上の領域やハードディスク６上のファイルなど）の開放や、当該ルーチン内で動的に接続された通信回線の切断に関わる処理などが考えられるが、本発明はこれに限定されない。ルーチン内で閉鎖的に行われ、必ず当該ルーチン内で完結しなければならない処理手続きは全てこれに該当する。この後処理手続きが終了した後、プロセッサの制御は呼び出し元である上位ルーチンに復帰する。【００２８】  一方、Ｓ１のＰ１またはＰ２で例外情報の発生を検出した場合は、当該ルーチンの通常処理を中止して、プロセッサ１は当該ルーチン内の例外情報の型に応じた例外ハンドラ（Ｓ２）に制御を移す。例外ハンドラでは、当該ルーチンに必要な後処理手続き（Ｓ２のＰ３）を行う。この時、この手続き部分も例外検査の対象となる（Ｓ２のＪ２）。この「後処理手続き」も、ルーチン内で閉鎖的に行われ、必ず当該ルーチン内で完結しなければならない処理手続きが全てこれに該当する。例えば前述したように、当該ルーチン内で動的に確保されたコンピュータ資源（例えばメモリ２上のメモリ領域やハードディスク６上のファイルなど）の開放処理などである。【００２９】  このような後処理手続きが終わった後、呼び出し元である上位のルーチンにプロセッサの制御を戻す。先にも述べたように例外処理時における上位ルーチンへの復帰の仕方としては、次の３通りがある。
（１）新たにメモリ２上に例外情報を確保し投入する
（２）下位ルーチンからのメモリ２上の例外情報をそのまま再投入する
（３）例外情報を投入しない
いずれの方法で上位ルーチンにプロセッサの制御を戻すかは、プログラムの記述に従って決定される。【００３０】  図３は本実施形態の例外処理方法が適用されたプログラムの階層構造の一例を示す図である。図３によって、前述した図２に示すようなルーチンを用いて構築したプログラムのルーチン間の連携について説明する。【００３１】図３に例示するプログラムでは、メインルーチンＭの処理内から２つのサブルーチンＳａ，Ｓｂがそれぞれのタイミングで呼び出され、サブルーチンＳａ，Ｓｂの処理の終了後にメインルーチンＭに戻って残りの処理を続行する。また、サブルーチンＳａの処理内でも２つのサブルーチンＳａ１，Ｓａ２がそれぞれのタイミングで呼び出され、サブルーチンＳａ１，Ｓａ２の処理の終了後にサブルーチンＳａに戻って残りの処理を続行する。また、サブルーチンＳｂの処理内でも２つのサブルーチンＳｂ１，Ｓｂ２がそれぞれのタイミングで呼び出され、サブルーチンＳｂ１，Ｓｂ２の処理の終了後にサブルーチンＳｂに戻って残りの処理を続行する。【００３２】  このようなプログラムの実行中に、例外情報を投入したり、或いは、下位ルーチンから例外情報が送出されてきた場合には、通常の処理手続きの実行を中止し、該当する例外情報の型に対応する例外ハンドラへプロセッサの制御を移す。例外ハンドラは当該ルーチンの後処理手続きを行なった後、上位ルーチンへプロセッサの制御を戻す。【００３３】  図３に示す例では、最下層のサブルーチンＳａ１で例外が発生したことに応答して、サブルーチンＳａ１は通常の処理を中止して、例外ハンドラを実行した後、上位のサブルーチンＳａに例外情報を投入すると同時にプロセッサの制御を戻す。また、最下層のサブルーチンＳａ１から例外情報を捕捉した上位のサブルーチンＳａは、通常の処理を中止して、例外ハンドラを実行した後、更に上位のメインルーチンＭに例外情報を投入すると同時にプロセッサの制御を戻す。  メインルーチンＭでは、サブルーチンＳａから例外情報を捕捉した場合、同様に通常の処理を中止して、例外ハンドラを実行した後、更に上位のルーチン（ＯＳ）に（例外を投入せずに）プロセッサの制御を戻す。即ち、ルーチンＭ，Ｓａ，Ｓａ１は全て、その後処理手続きを完了しており、かつＯＳまでプロセッサの制御が戻っている。【００３４】  なお、図３ではサブルーチンＳａ１→サブルーチンＳａ→メインルーチンＭ→ＯＳという流れに従って行われる例外処理について説明したが、本実施形態のプログラムに含まれるルーチンＭ，Ｓａ，Ｓａ１，Ｓａ２，Ｓｂ，Ｓｂ１，Ｓｂ２は全て、
【課題を解決するための手段】
の（１）〜（３）の要件を満たしているため、他のルートの流れに従って行われる例外処理についても同様となる。即ち、例外が発生したルーチンがどこであっても、メインルーチンから例外が発生したルーチンに至るまでの全てのルーチンについて、ルーチン毎に必要な後処理手続きを完了してＯＳまでプロセッサの制御が戻り得る。
【００３５】  次に、図４〜図７によって本実施形態によるプログラムの具体例を示す。これらの実施形態において、プロセッサを適用したコンピュータの構成、プログラム中に含まれる各ルーチンの動作は図１、図２と同様である。また、図４〜図７の例におけるプログラムの階層構造は図３の一部分を抜粋したものである（ＯＳ−メインルーチンＭ−サブルーチンＳａ−サブルーチンＳａ１）。なお、図４〜図７のプログラム例は、通常の処理は同じである。ただ、例外ハンドラの内容が異なる。具体的には、例外の判別に用いる情報の取得の有無やその出力方法が異なっている。「例外の判別に用いる情報」として、これらの例では、例外情報が発生あるいは例外処理を行う場所を示すプログラムソースファイル名とその行番号を用いているが、本発明はこれに限定されない。例外の判別に資する情報であれば良いので、例えば、予め定義されたエラー番号とそのエラーが発生したハードウェア名といった情報も考えられる。また、これらの例ではユーザー定義ルーチン以外のルーチンの例外処理は実装依存である。なお、図４〜図７のプログラム例は各々、本来同一のソースファイル上に記述されているが、ここでは紙面の都合上、ルーチン毎に３分割して示す（Ａ〜Ｃ）。
【００３６】  まず、通常の処理について説明する。通常の処理は図４〜図７のプログラム例全てで同じである。メインルーチンの基本的な処理内容は、下位ルーチンである関数Ｓａへ整数値”１”と”２”を渡し、関数Ｓａがその２つの整数値を用いて計算した結果を答えとしてディスプレイ５に表示するものである。また、関数Ｓａの基本的な処理内容は、上位ルーチンから渡された２つの整数値を下位ルーチンである関数Ｓａ１へ渡し、関数Ｓａ１がその２つの整数値を用いて計算した結果をメモリ２上に動的に確保した（ｎｅｗ演算子を使用）ｉｎｔ型データエリアに格納し、その整数値に１００を乗じてその値を上位ルーチン（メインルーチン）へ返す。そして、上位ルーチンにプロセッサの制御を戻す前に、メモリ２上に動的に確保したｉｎｔ型データエリアを開放（ｄｅｌｅｔｅ演算子を使用）する。また、関数Ｓａ１の基本的な処理内容は、上位ルーチンから渡された２つの整数値の和を計算し、その結果をメモリ２上に動的に確保した（ｎｅｗ演算子を使用）ｉｎｔ型データエリアに格納し、その整数値に２００を加算してその値を上位ルーチン（関数Ｓａ１）へ返す。そして、上位ルーチンにプロセッサの制御を戻す前に、メモリ２上に動的に確保したｉｎｔ型データエリアを開放（ｄｅｌｅｔｅ演算子を使用）する。その正常終了の結果は図４〜図７の全てのプログラム例で同じである（図４Ｄ）。
【００３７】  次に例外ハンドラで行う後処理手続きについて説明する。ここで行う後処理手続きは図４〜図７のプログラム例全てで同じである。即ち、メモリ２上に動的に確保したデータエリア（関数Ｓａでは＊ｐＩｎｔＳａ、関数Ｓａ１では＊ｐＩｎｔＳａ１）の開放（ｄｅｌｅｔｅ演算子を使用）である。補足すると、動的に確保したデータエリアのアドレスであるポインタ（ｐＩｎｔＳａ及びｐＩｎｔＳａ１）はデータエリアを動的に確保している時以外はゼロクリアされているので、仮に、データエリアを動的に確保していない場合に例外が発生し、プロセッサの制御が例外ハンドラに移ってデータエリアを開放したとしても問題は生じない。
【００３８】  図４（図４Ａ〜図４Ｃ）は、デバッグのための例外情報を投入しない最もシンプルな例である。この例は請求項１，７，８に相当する例である。
【００３９】  この例では、例外ハンドラで、メモリ２上のデータエリアを開放した後、捕捉したメモリ２上の例外情報をその外側にあるｃａｔｃｈブロックへそのまま再投入している。外側のｃａｔｃｈブロック内では捕捉した例外情報をそのまま上位ルーチンへ再投入している。つまり、通常の処理手続き中の何れの箇所で例外情報が発生してもメモリ２上のデータエリアの開放は行われる。また、捕捉したメモリ２上の例外情報は遺漏することなくメインルーチンまでそのまま引き継がれ、最終的にはメインルーチンで破棄され、ＯＳに例外情報を投入せずにプロセッサの制御を戻している。それにより意図しない強制終了は起こらない。
【００４０】  図４Ｅは図４Ｃの「Ｅｘｃｅｐｔｉｏｎ  ｏｃｃｕｒｒｅｄ」の箇所で意図的に例外情報を発生させて（図４Ｃでは注釈行にしている）実行した時のメッセージをディスプレイ５に表示した結果である。本実施形態では、プログラムソースはシンプルである反面、メッセージ出力をみれば明らかであるように例外発生箇所の特定が困難である。
【００４１】  図５（図５Ａ〜図５Ｃ）は、デバッグのための例外情報を投入する例であるが、その例外情報の出力はメインルーチンで一元的に行なっている例である。その他の処理は全て図４の例と同じである。この例は請求項１，３，７，８に相当する例である。
【００４２】  この例では、例外ハンドラで、例外情報が発生あるいは例外処理を行う場所を示すプログラムソースファイル名とその行番号をｓｐｒｉｎｔｆ標準ライブラリ関数によって文字列に編集してメモリ２上に展開し、それを新たに投入している。ただし、捕捉した例外情報が文字列型である場合は、捕捉した例外情報を破棄せずにそのまま上位ルーチンへ再投入する。そして、そのディスプレイ５への出力はメインルーチンのみで行う。捕捉したメモリ２上の例外情報は遺漏することなくサブルーチンで破棄される。また、例外情報が文字列型である場合は、メインルーチンまでそのまま引き継がれ、最終的にはメインルーチンで破棄される。そして、ＯＳに例外情報を投入せずにプロセッサの制御を戻している。それにより意図しない強制終了は起こらない。
【００４３】  図４Ｃと同様に図５Ｃの「Ｅｘｃｅｐｔｉｏｎ  ｏｃｃｕｒｒｅｄ」の箇所で意図的に例外情報を発生させて（図５Ｃでは注釈行にしている）実行した時のメッセージをディスプレイ５に表示した結果を図５Ｄに示す。それを見ると異常終了のメッセージと共に、例外情報が発生あるいは例外処理を行う場所をプログラムソースファイル名とその行番号によって特定している。これにより、例外情報の発生したルーチンとその例外情報の種類を判別することができるものである。その反面、本実施形態では、プログラムソースは多少複雑になる。
【００４４】  図６（図６Ａ〜図６Ｃ）も、デバッグのための例外情報を投入する例であるが、その例外情報の出力を各ルーチンで行なっている例である。その他の処理は全て図４、図５の例と同じである。この例も請求項１，３，７，８に相当する例である。
【００４５】  この例では、例外ハンドラで、例外情報が発生あるいは例外処理を行う場所を示すプログラムソースファイル名とその行番号をｓｐｒｉｎｔｆ標準ライブラリ関数によって文字列に編集してメモリ２上に展開し、それをそのつどディスプレイ５に表示している。その後、新たにｂｏｏｌ型例外情報（”ｔｒｕｅ”）をメモリ２上に確保し投入しているが、これは他の例外情報と重複しないためであって、重複しなければ他の型（例えばｄｏｕｂｌｅ型）の例外情報であっても差し支えない。捕捉したメモリ２上の例外情報は遺漏することなくサブルーチンで破棄される。また、サブルーチンがメインルーチンに投入するｂｏｏｌ型例外情報は最終的にはメインルーチンで破棄される。そして、ＯＳに例外情報を投入せずにプロセッサの制御を戻している。それにより意図しない強制終了は起こらない。
【００４６】  図４Ｃ、図５Ｃと同様に図６Ｃの「Ｅｘｃｅｐｔｉｏｎ  ｏｃｃｕｒｒｅｄ」の箇所で意図的に例外情報を発生させて（図６Ｃでは注釈行にしている）実行した時のメッセージをディスプレイ５に表示した結果を図６Ｄに示す。それを見ると異常終了のメッセージと共に、例外情報が発生あるいは例外処理を行う箇所をプログラムソースファイル名とその行番号によって特定しているが、図５Ｄの例と異なるのはルーチン毎にそのメッセージを出力していることである。これにより、例外情報の発生したルーチンとその例外情報の種類を判別することのみならず、例外情報の発生したルーチンからメインルーチンに至るまでのルートをトレースすることができる。この例では、例えばルーチンＳａ１が同一プログラム中の複数箇所で使用されていた場合でも、どの箇所で例外情報が発生したかをトレースし特定することが可能である。その反面、やはり本実施形態でも、プログラムソースは多少複雑になる。ちなみに、この例では例外情報をディスプレイ表示しているが、ハードディスク６などの固定記憶装置へファイルとして出力したり、メモリ２などの主記憶装置へ出力しても良い。
【００４７】  図７（図７Ａ〜図７Ｃ）は、実行ファイルを、デバッグのための例外情報を投入しない図４の例と同じにするか、デバッグのための例外情報を投入する図６の例と同じにするかをプログラムのコンパイル時に決定する例である。その他の処理は全て図４〜図６の例と同じである。この例は請求項１，５，７，８に相当する例である。
【００４８】  この例では、図７Ａの上方で”＃ｄｉｆｉｎｅ  ＤＥＢＵＧＭＯＤＥ”の記述がある。これはコンパイラに対する制御指令であり、このように、”ＤＥＢＵＧＭＯＤＥ”の定義がある場合はサブルーチンＳａ及びＳａ１において、”＃ｉｆ  ｄｅｆｉｎｅｄ  ＤＥＢＵＧＭＯＤＥ”と”＃ｅｌｓｅ”（ない場合は”＃ｅｎｄｉｆ”）の間の命令文がコンパイルされ、定義がない場合は”＃ｅｌｓｅ”と”＃ｅｎｄｉｆ”の間の命令文がコンパイルされる（”＃ｅｌｓｅ”がない場合はコンパイルされない）。また、捕捉したメモリ２上の例外情報は遺漏することなくサブルーチンまたはメインルーチンで破棄される。そして、ＯＳに例外情報を投入せずにプロセッサの制御を戻している。それにより意図しない強制終了は起こらない。
【００４９】  図４Ｃ等と同様に図７Ｃの「Ｅｘｃｅｐｔｉｏｎ  ｏｃｃｕｒｒｅｄ」の箇所で意図的に例外情報を発生させて（図７Ｃでは注釈行にしている）実行した時のメッセージをディスプレイ５に表示した結果は、”ＤＥＢＵＧＭＯＤＥ”の定義がある場合は図６Ｄと同様になり、”ＤＥＢＵＧＭＯＤＥ”の定義がない場合は図４Ｄと同様になる。このようにコンパイル時にプログラムソースを選択的にコンパイルする利点は、実行ファイルのサイズの違いにある。プログラム開発途中などの場合は、”ＤＥＢＵＧＭＯＤＥ”を定義してコンパイルすることにより、より多くのデバッグ情報を得ることができるが、実行ファイルのサイズはその分大きくなる。プログラムのデバッグ作業が終了し製品として配布する場合は”ＤＥＢＵＧＭＯＤＥ”を定義せずにコンパイルすることにより、実行ファイルのサイズを抑えることができる。
【００５０】  その他、上記実施形態は、何れも本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【産業上の利用可能性】
【００５１】  本発明の例外処理方法、プロセッサおよびコンピュータ読み取り可能なプログラムは、ソフトウェアを使用する情報処理技術の分野全般で利用可能である。異常終了時にコンピュータ資源の解放等を行わない類のＯＳ上で動作するアプリケーションプログラムの開発はもちろん、ＯＳ等のシステムプログラムの開発にも有効である。またＯＳのないハードウェア上で直接動作するアプリケーションプログラムの開発にも有用である。
【図面の簡単な説明】
【００５２】
【図１】  本実施形態のプロセッサを適用したコンピュータの構成例を示すブロック図である。
【図２】  本実施形態の例外処理方法が適用されたプログラムを構成する各ルーチンの動作を示すフローチャートである。
【図３】  本実施形態の例外処理方法が適用されたプログラムの階層構造の一例を示す図である。
【図４Ａ】  本実施形態による第１のプログラム例（メインルーチン）を示す図である。
【図４Ｂ】  本実施形態による第１のプログラム例（サブルーチン）を示す図である。
【図４Ｃ】  本実施形態による第１のプログラム例（サブルーチン）を示す図である。
【図４Ｄ】  第１〜第４のプログラム例の正常終了時にディスプレイに表示される画面例を示す図である。
【図４Ｅ】  第１及び第４のプログラム例の実行時に例外が発生した場合にディスプレイに表示される画面例を示す図である。
【図５Ａ】  本実施形態による第２のプログラム例（メインルーチン）を示す図である。
【図５Ｂ】  本実施形態による第２のプログラム例（サブルーチン）を示す図である。
【図５Ｃ】  本実施形態による第２のプログラム例（サブルーチン）を示す図である。
【図５Ｄ】  第２のプログラム例の実行時に例外が発生した場合にディスプレイに表示される画面例を示す図である。
【図６Ａ】  本実施形態による第３のプログラム例（メインルーチン）を示す図である。
【図６Ｂ】  本実施形態による第３のプログラム例（サブルーチン）を示す図である。
【図６Ｃ】  本実施形態による第３のプログラム例（サブルーチン）を示す図である。
【図６Ｄ】  第３及び第４のプログラム例の実行時に例外が発生した場合にディスプレイに表示される画面例を示す図である。
【図７Ａ】  本実施形態による第４のプログラム例（メインルーチン）を示す図である。
【図７Ｂ】  本実施形態による第４のプログラム例（サブルーチン）を示す図である。
【図７Ｃ】  本実施形態による第４のプログラム例（サブルーチン）を示す図である。
【符号の説明】
【００５３】  １  プロセッサ
２  メモリ
３  ディスプレイコントローラ
４  ＨＤＤコントローラ
５  ディスプレイ
６  ハードディスク
【図１】
2006127440.tif 000003
【図２】
2006127440.tif 000004
【図３】
2006127440.tif 000005
【図４Ａ】
2006127440.tif 000006
【図４Ｂ】
2006127440.tif 000007
【図４Ｃ】
2006127440.tif 000008
【図４Ｄ】
2006127440.tif 000009
【図４Ｅ】
2006127440.tif 000010
【図５Ａ】
2006127440.tif 000011
【図５Ｂ】
2006127440.tif 000012
【図５Ｃ】
2006127440.tif 000013
【図５Ｄ】
2006127440.tif 000014
【図６Ａ】
2006127440.tif 000015
【図６Ｂ】
2006127440.tif 000016
【図６Ｃ】
2006127440.tif 000017
【図６Ｄ】
2006127440.tif 000018
【図７Ａ】
2006127440.tif 000019
【図７Ｂ】
2006127440.tif 000020
【図７Ｃ】
2006127440.tif 000021