JP2006127440A - 敷衍化した例外処理方法、およびそのコンピュータ読み取り可能なプログラム - Google Patents
敷衍化した例外処理方法、およびそのコンピュータ読み取り可能なプログラム Download PDFInfo
- Publication number
- JP2006127440A JP2006127440A JP2004344898A JP2004344898A JP2006127440A JP 2006127440 A JP2006127440 A JP 2006127440A JP 2004344898 A JP2004344898 A JP 2004344898A JP 2004344898 A JP2004344898 A JP 2004344898A JP 2006127440 A JP2006127440 A JP 2006127440A
- Authority
- JP
- Japan
- Prior art keywords
- exception
- information
- program
- processor
- processing procedure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
【課題】 ルーチン間における例外処理の一貫性や連携の欠如により、例外捕捉の漏洩やプログラムの開発生産性の低下を招くという不都合を解決すること。
【解決手段】 例外処理をルーチン単位で行なう。その場合、例外検査範囲をルーチンの全手続き部分とし、かつ、全ての型の例外情報を捕捉する。そしてプログラム中で使用するルーチンは全て(または、少なくともユーザー定義部分のみは)その条件を満たす。例外が発生した場合は、通常の処理を中止して、必要な後処理を行なった後、上位ルーチンへ制御を戻す。その時、必要に応じて上位ルーチンへ例外情報を投入する。
【選択図】 図3
【解決手段】 例外処理をルーチン単位で行なう。その場合、例外検査範囲をルーチンの全手続き部分とし、かつ、全ての型の例外情報を捕捉する。そしてプログラム中で使用するルーチンは全て(または、少なくともユーザー定義部分のみは)その条件を満たす。例外が発生した場合は、通常の処理を中止して、必要な後処理を行なった後、上位ルーチンへ制御を戻す。その時、必要に応じて上位ルーチンへ例外情報を投入する。
【選択図】 図3
Description
本発明は、コンピュータ・ソフトウェアの例外処理方法、特に複数のルーチン間を適宜移行しながら一連の処理を行うように記述されたプログラムの実行時に例外が発生した場合の例外処理方法に用いて好適なものである。
現在、プログラム開発は、例えばアセンブリ言語、C,C++などのコンピュータ言語によってソースコードを記述し、そのソースコードをアセンブル又は、コンパイルすることでCPUが実行可能な形式の実行ファイルに加工するのが一般的である。このようにして生成されるプログラムの殆どは、メインルーチン及びサブルーチンを含む複数のルーチンプログラムの組み合わせから構成されている。
この種のプログラムは、複数のルーチン間を適宜移行しながら一連の処理を行うようになっている。ところが、その一連の処理の途中でエラーが発生し、ルーチン内のそれ以降の処理手続きを行うことに支障を生じることがある。このような場合には、プログラムの記述に従って例外処理が実行される。
C++などで記述されるプログラムでは、エラーが発生した場合、ユーザー自身のプログラム定義によって、例外情報を生成し、例外を発生させることができる。このように一般に、例外情報を生成し、例外を発生させることを、「例外(または例外情報)を投入(または送出)する」と言う。また、プログラム内で使用する関数や演算子などのサブルーチンが例外を投入することもある。例外処理とは、そのように例外が投入された場合、それ以降の処理を打ち切って例外情報を捕捉するハンドラ(これを例外ハンドラという)内で、発生した例外を適切に処理することを言う。
そして、例えば、現在広く普及している、いわゆるC++系言語では、例外の発生の有無を検査する範囲を”try”句で範囲指定する。また、それに対応した例外ハンドラは、それに引き続いて記述された”catch”ブロック内で記述する。
しかし、従来、例外処理は各企業、各プログラマの裁量により、部分的に行われているに過ぎず、全てのルーチン間で一貫性を保ち、連携をとるという発想はなかった。そのような例外処理に関する一貫性の欠如は種々の不都合を招く。
まず、例外情報捕捉の漏洩が発生し、プログラムが強制終了してしまうという危険がある。また、そのような漏洩は、当該ルーチンを終了する前に、当該ルーチンで行うべき後処理手続きを行うことなく終了もしくはリターンしてしまうという事態をもたらし、結果としてプログラムの安定性を著しく低下させたり、更には他のプログラムの実行に支障をきたしてしまう場合さえある。ここで言う「後処理手続き」とは、例えば、当該ルーチン内で動的に確保されたコンピュータ資源(例えばメモリ領域やファイルなど)の開放や、当該ルーチン内で動的に接続された通信回線の切断に関わる処理などが考えられる。
また、そのような一貫性のない例外処理は、ルーチン間での例外処理の連携に、常に個別対応的な注意を払わねばならず、ルーチンの汎用性や再利用性を大きく損なう。それがひいては、プログラミング作業に於ける大きな負担となり、プログラミングの開発生産性やメンテナンス性に少なからぬ影響を及ぼすことになる。
例外処理を敷衍することにより解決する。具体的には下記(1)〜(3)の要件を満たしたルーチンのみの組み合わせにより、プログラムを構築する。請求項1においては、ユーザー定義ルーチンのみをその要件の対象とし、演算子やライブラリ関数等の実装に依存するルーチンについては、必ずしも下記(1)〜(3)の要件を満たすことを要求しないが、請求項2においては、実装に依存するルーチンを含む全てのルーチンに、下記(1)〜(3)の要件を満たすことを要求する。
(1)例外の検査範囲は、各ルーチンの全ての手続き部分(例外ハンドラ部も含む)とする。
(2)全てのデータ型の例外情報を検査対象とする。
(3)例外が発生した場合は、通常の処理を中止して、例外ハンドラにプロセッサの制御を移す。例外ハンドラは当該ルーチンの必要とする後処理手続き等を行なった後、上位ルーチンへプロセッサの制御を戻す。そのリターンの方法は次の3通りである。
▲1▼新たにメモリ上に例外情報を確保し投入する
▲2▼下位ルーチンからのメモリ上の例外情報をそのまま再投入する
▲3▼例外情報を投入しない
▲1▼新たにメモリ上に例外情報を確保し投入する
▲2▼下位ルーチンからのメモリ上の例外情報をそのまま再投入する
▲3▼例外情報を投入しない
一貫性があり、ルーチン間で連携がとれている例外処理が可能になった。それにより、次のような効果を期待できる。
(1)全ルーチンで全ての例外情報を捕捉するので、例外情報捕捉の漏洩による自動的な強制終了がなくなる。
(2)例外処理に関するルーチン間の連携を過度に気にすることなく、各ルーチンをあたかも部品のごとく再利用することが容易になる。そして、例えば、ルーチン内に,例外を送出するルーチンを追加するようなメンテナンスもまた同様に容易になる。
(3)例外が発生したルーチンがかなり深い階層であっても、メインルーチンから例外が発生したルーチンに至るまでの全てのルーチンについて、ルーチン毎に必要な後処理手続きを完了して,メインルーチンまたはOSまでプロセッサの制御が戻り得ることを示している。従って例外ハンドラ部で行う後処理手続き内で、例えば当該ルーチン内で動的に確保したコンピュータ資源を開放する処理を行うならば、全てのルーチンの全ての資源を確実に解放し得ることを意味している。
(4)例外ハンドラ部で、適切な情報を含んだ例外情報を投入したり、またそのような例外情報を表示装置や種々の記憶装置(例えばメモリやハードディスクなど)へ出力することにより例外発生箇所を特定する作業が容易になる。
以下、本発明の実施の形態を図面に基づいて説明する。
図1は、本実施形態のプロセッサ適用したコンピュータの構成例を示すブロック図である。
図1において、プロセッサ1はコンピュータの全体を制御するものであり、本実施形態のプログラムを実行する。このプロセッサ1は、本発明の例外処理手段としてコンピュータを機能させるものである。
メモリ2は、プロセッサ1が行う処理の過程で得られるデータや、処理の結果得られるデータを一時的に格納する。プロセッサ1がプログラムを実行する際には、まずメモリ2上に必要な容量の領域を割り当て、これによって確保したメモリ領域を使って処理を実行する。そして、処理の終了後には、最初に確保したメモリ領域を開放する。
ディスプレイコントローラ3はプロセッサ1から与えられる表示命令に従って、各種情報をディスプレイ5に表示するための制御を実行する。例えば、ディスプレイコントローラ3は、プロセッサ1による処理の実行結果をディスプレイ5に表示する。また、プロセッサ1による処理の途中で例外が発生し、例外ハンドラ中にエラー情報の表示命令がある場合には、ディスプレイコントローラ3はプロセッサ1から出力された所定のエラー情報をディスプレイ5に表示する。
HDDコントローラ4は、プロセッサ1から与えられる制御命令に従って、ハードディスク(HDD)6に対するデータの読み書きを制御する。本実施形態のプログラムは、このハードディスク6に格納されている。また、このプログラムが開いて使用する種々のファイルも、ハードディスク6に格納されている。プロセッサ1は、HDDコントローラ4を制御してハードディスク6からプログラムの命令文を適宜読み出し、メモリ2上に展開して、メモリ2上に確保した領域をワークメモリとして使用しながら所定の処理を実行する。その際、必要であればハードディスク6からファイルを読み出し、これを開いて使用する。
このハードディスク6に格納されているプログラムは、本発明のプログラムを構成する。このプログラムを記録する記録媒体としては、ハードディスク6以外に、ROM,CD−ROM,フレキシブルディスク、磁気テープ、光ディスク、光磁気ディスク、DVD,不揮発性メモリカード等を用いることができる。また、インターネット等のネットワークを介してコンピュータにプログラムをダウンロードするようにしても良い。
次に図2を用いて本実施形態のプログラムを構成する各ルーチンの動作を説明する。図2は、本実施形態のプログラムを構成する各ルーチンの内部構造である。
図2において、ルーチンの処理が開始すると、まずプロセッサ1は命令を逐次実行してゆく(S1のP1やP2)が、その途中で例外情報が発生したか否かを判定する(S1のJ1)。判定すべき例外情報の型は、全てのデータ型(int型やchar型などの基本データ型のみならず、クラスや構造体などの独自のデータ型も含む)が対象であるが、必要に応じて、ある特定の型に対してのみ、独自の処理を施すことも可能である。
例外情報が発生していない場合は、そのルーチンの処理を通常通り実行する(S1のP1)。そしてその通常の処理が終了すると、プロセッサ1は、そのルーチンに必要な後処理手続きを実行する(S1のP2)。ここで言う後処理手続きとは、例えば、当該ルーチン内で動的に確保されたコンピュータ資源(例えばメモリ2上の領域やハードディスク6上のファイルなど)の開放や、当該ルーチン内で動的に接続された通信回線の切断に関わる処理などが考えられるが、本発明はこれに限定されない。ルーチン内で閉鎖的に行われ、必ず当該ルーチン内で完結しなければならない処理手続きは全てこれに該当する。この後処理手続きが終了した後、プロセッサの制御は呼び出し元である上位ルーチンに復帰する。
一方、S1のP1またはP2で例外情報の発生を検出した場合は、当該ルーチンの通常処理を中止して、プロセッサ1は当該ルーチン内の例外情報の型に応じた例外ハンドラ(S2)に制御を移す。例外ハンドラでは、当該ルーチンに必要な後処理手続き(S2のP3)を行う。この時、この手続き部分も例外検査の対象となる(S2のJ2)。この「後処理手続き」も、ルーチン内で閉鎖的に行われ、必ず当該ルーチン内で完結しなければならない処理手続きが全てこれに該当する。例えば前述したように、当該ルーチン内で動的に確保されたコンピュータ資源(例えばメモリ2上のメモリ領域やハードディスク6上のファイルなど)の開放処理などである。
このような後処理手続きが終わった後、呼び出し元である上位のルーチンにプロセッサの制御を戻す。先にも述べたように例外処理時における上位ルーチンへの復帰の仕方としては、次の3通りがある。
(1)新たにメモリ2上に例外情報を確保し投入する
(2)下位ルーチンからのメモリ2上の例外情報をそのまま再投入する
(3)例外情報を投入しない
いずれの方法で上位ルーチンにプロセッサの制御を戻すかは、プログラムの記述に従って決定される。
(1)新たにメモリ2上に例外情報を確保し投入する
(2)下位ルーチンからのメモリ2上の例外情報をそのまま再投入する
(3)例外情報を投入しない
いずれの方法で上位ルーチンにプロセッサの制御を戻すかは、プログラムの記述に従って決定される。
図3は本実施形態の例外処理方法が適用されたプログラムの階層構造の一例を示す図である。図3によって、前述した図2に示すようなルーチンを用いて構築したプログラムのルーチン間の連携について説明する。
図3に例示するプログラムでは、メインルーチンMの処理内から2つのサブルーチンSa,Sbがそれぞれのタイミングで呼び出され、サブルーチンSa,Sbの処理の終了後にメインルーチンMに戻って残りの処理を続行する。また、サブルーチンSaの処理内でも2つのサブルーチンSa1,Sa2がそれぞれのタイミングで呼び出され、サブルーチンSa1,Sa2の処理の終了後にサブルーチンSaに戻って残りの処理を続行する。また、サブルーチンSbの処理内でも2つのサブルーチンSb1,Sb2がそれぞれのタイミングで呼び出され、サブルーチンSb1,Sb2の処理の終了後にサブルーチンSbに戻って残りの処理を続行する。
このようなプログラムの実行中に、例外情報を投入したり、或いは、下位ルーチンから例外情報が送出されてきた場合には、通常の処理手続きの実行を中止し、該当する例外情報の型に対応する例外ハンドラへプロセッサの制御を移す。例外ハンドラは当該ルーチンの後処理手続きを行なった後、上位ルーチンへプロセッサの制御を戻す。
図3に示す例では、最下層のサブルーチンSa1で例外が発生したことに応答して、サブルーチンSa1は通常の処理を中止して、例外ハンドラを実行した後、上位のサブルーチンSaに例外情報を投入すると同時にプロセッサの制御を戻す。また、最下層のサブルーチンSa1から例外情報を捕捉した上位のサブルーチンSaは、通常の処理を中止して、例外ハンドラを実行した後、更に上位のメインルーチンMに例外情報を投入すると同時にプロセッサの制御を戻す。 メインルーチンMでは、サブルーチンSaから例外情報を捕捉した場合、同様に通常の処理を中止して、例外ハンドラを実行した後、更に上位のルーチン(OS)に(例外を投入せずに)プロセッサの制御を戻す。即ち、ルーチンM,Sa,Sa1は全て、その後処理手続きを完了しており、かつOSまでプロセッサの制御が戻っている。
なお、図3ではサブルーチンSa1→サブルーチンSa→メインルーチンM→OSという流れに従って行われる例外処理について説明したが、本実施形態のプログラムに含まれるルーチンM,Sa,Sa1,Sa2,Sb,Sb1,Sb2は全て、
の(1)〜(3)の要件を満たしているため、他のルートの流れに従って行われる例外処理についても同様となる。即ち、例外が発生したルーチンがどこであっても、メインルーチンから例外が発生したルーチンに至るまでの全てのルーチンについて、ルーチン毎に必要な後処理手続きを完了してOSまでプロセッサの制御が戻り得る。
次に、図4〜図7によって本実施形態によるプログラムの具体例を示す。これらの実施形態において、プロセッサを適用したコンピュータの構成、プログラム中に含まれる各ルーチンの動作は図1、図2と同様である。また、図4〜図7の例におけるプログラムの階層構造は図3の一部分を抜粋したものである(OS−メインルーチンM−サブルーチンSa−サブルーチンSa1)。なお、図4〜図7のプログラム例は、通常の処理は同じである。ただ、例外ハンドラの内容が異なる。具体的には、例外の判別に用いる情報の取得の有無やその出力方法が異なっている。「例外の判別に用いる情報」として、これらの例では、例外情報が発生あるいは例外処理を行う場所を示すプログラムソースファイル名とその行番号を用いているが、本発明はこれに限定されない。例外の判別に資する情報であれば良いので、例えば、予め定義されたエラー番号とそのエラーが発生したハードウェア名といった情報も考えられる。また、これらの例ではユーザー定義ルーチン以外のルーチンの例外処理は実装依存である。なお、図4〜図7のプログラム例は各々、本来同一のソースファイル上に記述されているが、ここでは紙面の都合上、ルーチン毎に3分割して示す(A〜C)。
まず、通常の処理について説明する。通常の処理は図4〜図7のプログラム例全てで同じである。メインルーチンの基本的な処理内容は、下位ルーチンである関数Saへ整数値”1”と”2”を渡し、関数Saがその2つの整数値を用いて計算した結果を答えとしてディスプレイ5に表示するものである。また、関数Saの基本的な処理内容は、上位ルーチンから渡された2つの整数値を下位ルーチンである関数Sa1へ渡し、関数Sa1がその2つの整数値を用いて計算した結果をメモリ2上に動的に確保した(new演算子を使用)int型データエリアに格納し、その整数値に100を乗じてその値を上位ルーチン(メインルーチン)へ返す。そして、上位ルーチンにプロセッサの制御を戻す前に、メモリ2上に動的に確保したint型データエリアを開放(delete演算子を使用)する。また、関数Sa1の基本的な処理内容は、上位ルーチンから渡された2つの整数値の和を計算し、その結果をメモリ2上に動的に確保した(new演算子を使用)int型データエリアに格納し、その整数値に200を加算してその値を上位ルーチン(関数Sa1)へ返す。そして、上位ルーチンにプロセッサの制御を戻す前に、メモリ2上に動的に確保したint型データエリアを開放(delete演算子を使用)する。その正常終了の結果は図4〜図7の全てのプログラム例で同じである(図4D)。
次に例外ハンドラで行う後処理手続きについて説明する。ここで行う後処理手続きは図4〜図7のプログラム例全てで同じである。即ち、メモリ2上に動的に確保したデータエリア(関数Saでは*pIntSa、関数Sa1では*pIntSa1)の開放(delete演算子を使用)である。補足すると、動的に確保したデータエリアのアドレスであるポインタ(pIntSa及びpIntSa1)はデータエリアを動的に確保している時以外はゼロクリアされているので、仮に、データエリアを動的に確保していない場合に例外が発生し、プロセッサの制御が例外ハンドラに移ってデータエリアを開放したとしても問題は生じない。
図4(図4A〜図4C)は、デバッグのための例外情報を投入しない最もシンプルな例である。この例は請求項1,7,8に相当する例である。
この例では、例外ハンドラで、メモリ2上のデータエリアを開放した後、捕捉したメモリ2上の例外情報をその外側にあるcatchブロックへそのまま再投入している。外側のcatchブロック内では捕捉した例外情報をそのまま上位ルーチンへ再投入している。つまり、通常の処理手続き中の何れの箇所で例外情報が発生してもメモリ2上のデータエリアの開放は行われる。また、捕捉したメモリ2上の例外情報は遺漏することなくメインルーチンまでそのまま引き継がれ、最終的にはメインルーチンで破棄され、OSに例外情報を投入せずにプロセッサの制御を戻している。それにより意図しない強制終了は起こらない。
図4Eは図4Cの「Exception occurred」の箇所で意図的に例外情報を発生させて(図4Cでは注釈行にしている)実行した時のメッセージをディスプレイ5に表示した結果である。本実施形態では、プログラムソースはシンプルである反面、メッセージ出力をみれば明らかであるように例外発生箇所の特定が困難である。
図5(図5A〜図5C)は、デバッグのための例外情報を投入する例であるが、その例外情報の出力はメインルーチンで一元的に行なっている例である。その他の処理は全て図4の例と同じである。この例は請求項1,3,7,8に相当する例である。
この例では、例外ハンドラで、例外情報が発生あるいは例外処理を行う場所を示すプログラムソースファイル名とその行番号をsprintf標準ライブラリ関数によって文字列に編集してメモリ2上に展開し、それを新たに投入している。ただし、捕捉した例外情報が文字列型である場合は、捕捉した例外情報を破棄せずにそのまま上位ルーチンへ再投入する。そして、そのディスプレイ5への出力はメインルーチンのみで行う。捕捉したメモリ2上の例外情報は遺漏することなくサブルーチンで破棄される。また、例外情報が文字列型である場合は、メインルーチンまでそのまま引き継がれ、最終的にはメインルーチンで破棄される。そして、OSに例外情報を投入せずにプロセッサの制御を戻している。それにより意図しない強制終了は起こらない。
図4Cと同様に図5Cの「Exception occurred」の箇所で意図的に例外情報を発生させて(図5Cでは注釈行にしている)実行した時のメッセージをディスプレイ5に表示した結果を図5Dに示す。それを見ると異常終了のメッセージと共に、例外情報が発生あるいは例外処理を行う場所をプログラムソースファイル名とその行番号によって特定している。これにより、例外情報の発生したルーチンとその例外情報の種類を判別することができるものである。その反面、本実施形態では、プログラムソースは多少複雑になる。
図6(図6A〜図6C)も、デバッグのための例外情報を投入する例であるが、その例外情報の出力を各ルーチンで行なっている例である。その他の処理は全て図4、図5の例と同じである。この例も請求項1,3,7,8に相当する例である。
この例では、例外ハンドラで、例外情報が発生あるいは例外処理を行う場所を示すプログラムソースファイル名とその行番号をsprintf標準ライブラリ関数によって文字列に編集してメモリ2上に展開し、それをそのつどディスプレイ5に表示している。その後、新たにbool型例外情報(”true”)をメモリ2上に確保し投入しているが、これは他の例外情報と重複しないためであって、重複しなければ他の型(例えばdouble型)の例外情報であっても差し支えない。捕捉したメモリ2上の例外情報は遺漏することなくサブルーチンで破棄される。また、サブルーチンがメインルーチンに投入するbool型例外情報は最終的にはメインルーチンで破棄される。そして、OSに例外情報を投入せずにプロセッサの制御を戻している。それにより意図しない強制終了は起こらない。
図4C、図5Cと同様に図6Cの「Exception occurred」の箇所で意図的に例外情報を発生させて(図6Cでは注釈行にしている)実行した時のメッセージをディスプレイ5に表示した結果を図6Dに示す。それを見ると異常終了のメッセージと共に、例外情報が発生あるいは例外処理を行う箇所をプログラムソースファイル名とその行番号によって特定しているが、図5Dの例と異なるのはルーチン毎にそのメッセージを出力していることである。これにより、例外情報の発生したルーチンとその例外情報の種類を判別することのみならず、例外情報の発生したルーチンからメインルーチンに至るまでのルートをトレースすることができる。この例では、例えばルーチンSa1が同一プログラム中の複数箇所で使用されていた場合でも、どの箇所で例外情報が発生したかをトレースし特定することが可能である。その反面、やはり本実施形態でも、プログラムソースは多少複雑になる。ちなみに、この例では例外情報をディスプレイ表示しているが、ハードディスク6などの固定記憶装置へファイルとして出力したり、メモリ2などの主記憶装置へ出力しても良い。
図7(図7A〜図7C)は、実行ファイルを、デバッグのための例外情報を投入しない図4の例と同じにするか、デバッグのための例外情報を投入する図6の例と同じにするかをプログラムのコンパイル時に決定する例である。その他の処理は全て図4〜図6の例と同じである。この例は請求項1,5,7,8に相当する例である。
この例では、図7Aの上方で”#difine DEBUGMODE”の記述がある。これはコンパイラに対する制御指令であり、このように、”DEBUGMODE”の定義がある場合はサブルーチンSa及びSa1において、”#if defined DEBUGMODE”と”#else”(ない場合は”#endif”)の間の命令文がコンパイルされ、定義がない場合は”#else”と”#endif”の間の命令文がコンパイルされる(”#else”がない場合はコンパイルされない)。また、捕捉したメモリ2上の例外情報は遺漏することなくサブルーチンまたはメインルーチンで破棄される。そして、OSに例外情報を投入せずにプロセッサの制御を戻している。それにより意図しない強制終了は起こらない。
図4C等と同様に図7Cの「Exception occurred」の箇所で意図的に例外情報を発生させて(図7Cでは注釈行にしている)実行した時のメッセージをディスプレイ5に表示した結果は、”DEBUGMODE”の定義がある場合は図6Dと同様になり、”DEBUGMODE”の定義がない場合は図4Dと同様になる。このようにコンパイル時にプログラムソースを選択的にコンパイルする利点は、実行ファイルのサイズの違いにある。プログラム開発途中などの場合は、”DEBUGMODE”を定義してコンパイルすることにより、より多くのデバッグ情報を得ることができるが、実行ファイルのサイズはその分大きくなる。プログラムのデバッグ作業が終了し製品として配布する場合は”DEBUGMODE”を定義せずにコンパイルすることにより、実行ファイルのサイズを抑えることができる。
その他、上記実施形態は、何れも本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
本発明の例外処理方法、プロセッサおよびコンピュータ読み取り可能なプログラムは、ソフトウェアを使用する情報処理技術の分野全般で利用可能である。異常終了時にコンピュータ資源の解放等を行わない類のOS上で動作するアプリケーションプログラムの開発はもちろん、OS等のシステムプログラムの開発にも有効である。またOSのないハードウェア上で直接動作するアプリケーションプログラムの開発にも有用である。
1 プロセッサ
2 メモリ
3 ディスプレイコントローラ
4 HDDコントローラ
5 ディスプレイ
6 ハードディスク
2 メモリ
3 ディスプレイコントローラ
4 HDDコントローラ
5 ディスプレイ
6 ハードディスク
Claims (8)
- 複数のルーチン間を適宜移行しながら一連の処理を行うように記述されたプログラムの実行時に例外が発生した場合の例外処理方法であって、そのプログラムを構成するユーザー定義ルーチンの全てが、プロセッサが行う処理手続き部の全範囲で、メモリ上に存在する全データ型の例外情報の発生の有無を検査し、例外情報の発生時にプロセッサが行う処理手続き中でルーチン毎に必要な後処理手続きを行なった後、呼び出し元へプロセッサの制御を戻すことを特徴とする例外処理方法。
- 上記プログラムを構成するルーチンの全てが、プロセッサが行う処理手続き部の全範囲で、メモリ上に存在する全データ型の例外情報の発生の有無を検査し、例外情報の発生時にプロセッサが行う処理手続き中でルーチン毎に必要な後処理手続きを行なった後、呼び出し元へプロセッサの制御を戻すことを特徴とする例外処理方法。
- 上記プログラムを構成するユーザー定義ルーチン全てが、上記例外情報発生時にプロセッサが行う処理手続き中に、例外の判別に用いる情報をメモリ上に確保する処理手続き、その情報を種々の表示装置や記憶装置に出力する処理手続き、その情報を例外情報として呼び出し元に投入しつつプロセッサの制御を戻す処理手続き、その例外情報を種々の表示装置や記憶装置に出力する処理手続きの何れか1つ以上を含むことによる例外判別機能を有することを特徴とする請求項1または2に記載の例外処理方法。
- 上記プログラムを構成するルーチンの全てが、上記例外情報発生時にプロセッサが行う処理手続き中に、例外の判別に用いる情報をメモリ上に確保する処理手続き、その情報を種々の表示装置や記憶装置に出力する処理手続き、その情報を例外情報として呼び出し元に投入しつつプロセッサの制御を戻す処理手続き、その例外情報を種々の表示装置や記憶装置に出力する処理手続きの何れか1つ以上を含むことによる例外判別機能を有することを特徴とする請求項1または2に記載の例外処理方法。
- 上記プログラムを構成するユーザー定義ルーチン全てに関して、上記例外情報発生時にプロセッサが行う請求項3に記載の例外判別のための処理手続きをコンパイラ又はアセンブラに対する制御指令によって選択的に決定して例外判別機能の統一をとり、その後実行ファイル形式に変換することにより例外判別機能を有することを特徴とする請求項1または2に記載の例外処理方法。
- 上記プログラムを構成するルーチン全てに関して、上記例外情報発生時にプロセッサが行う請求項4に記載の例外判別のための処理手続きをコンパイラ又はアセンブラに対する制御指令によって選択的に決定して例外判別機能の統一をとり、その後実行ファイル形式に変換することにより例外判別機能を有することを特徴とする請求項1または2に記載の例外処理方法。
- 上記プログラムを構成するユーザー定義ルーチンの全てを記述するプログラミング言語を、C++言語とすることを特徴とする請求項1〜6に記載の例外処理方法。
- 請求項1〜7の何れか1項に記載の例外処理方法の処理手続きをコンピュータに実行させるためのコンピュータ読み取り可能なプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004344898A JP2006127440A (ja) | 2004-10-29 | 2004-10-29 | 敷衍化した例外処理方法、およびそのコンピュータ読み取り可能なプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004344898A JP2006127440A (ja) | 2004-10-29 | 2004-10-29 | 敷衍化した例外処理方法、およびそのコンピュータ読み取り可能なプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2006127440A true JP2006127440A (ja) | 2006-05-18 |
Family
ID=36722099
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004344898A Pending JP2006127440A (ja) | 2004-10-29 | 2004-10-29 | 敷衍化した例外処理方法、およびそのコンピュータ読み取り可能なプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2006127440A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010534891A (ja) * | 2007-07-26 | 2010-11-11 | アビニシオ テクノロジー エルエルシー | エラーハンドリングをもつトランザクションのグラフ型計算 |
JP2013080281A (ja) * | 2011-09-30 | 2013-05-02 | Fujitsu Ltd | 実行制御プログラム、コンパイラ、実行制御装置および実行制御方法 |
-
2004
- 2004-10-29 JP JP2004344898A patent/JP2006127440A/ja active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010534891A (ja) * | 2007-07-26 | 2010-11-11 | アビニシオ テクノロジー エルエルシー | エラーハンドリングをもつトランザクションのグラフ型計算 |
JP2013080281A (ja) * | 2011-09-30 | 2013-05-02 | Fujitsu Ltd | 実行制御プログラム、コンパイラ、実行制御装置および実行制御方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8813037B2 (en) | Debugging a high performance computing program | |
KR101004543B1 (ko) | 디버깅 방법, 디버그 시스템, 및 컴퓨터 판독가능한 저장 매체 | |
Bousse et al. | Omniscient debugging for executable DSLs | |
US20060200806A1 (en) | Apparatus, system, and method for trace insertion | |
US10545852B2 (en) | Diagnostics of state transitions | |
JP2006185211A (ja) | プログラム解析装置、テスト実行装置、その解析方法及びプログラム | |
US20120131559A1 (en) | Automatic Program Partition For Targeted Replay | |
US8127275B1 (en) | System and method for recording the state of variables and objects when running unit tests | |
Saff et al. | Continuous testing in Eclipse | |
US8751872B2 (en) | Separation of error information from error propagation information | |
US7624381B1 (en) | Portable detection of start and completion of object construction | |
JP2009237610A (ja) | コード変換装置及びコード変換方法 | |
Hamann et al. | OCL-based runtime monitoring of JVM hosted applications | |
US11074153B2 (en) | Collecting application state in a runtime environment for reversible debugging | |
JP2011170749A (ja) | シミュレーション装置及びシミュレーション方法 | |
JP2006127440A (ja) | 敷衍化した例外処理方法、およびそのコンピュータ読み取り可能なプログラム | |
EP3635561B1 (en) | Asynchronous operation query | |
US6178547B1 (en) | Method and apparatus for generating non-redundant symbolic debug information in computer programs | |
CN111367796A (zh) | 应用程序调试方法及装置 | |
JP3745968B2 (ja) | 試験システム及び試験方法及び試験プログラム及び試験プログラムを記録した計算機で読み取り可能な記録媒体 | |
Tominaga et al. | AwaitViz: a visualizer of JavaScript's async/await execution order | |
Wu et al. | Debug concurrent programs with visualization and inference of event structure | |
Edwards et al. | AFID: an automated approach to collecting software faults | |
JP3095556B2 (ja) | プロセッサ機構のオンライン試験方法 | |
JP2005332110A (ja) | シミュレーションシステム |