酢こんぶの思考錯誤(^_^;日記

酢こんぶの自作ソフト「ExecS」はVisualBasic2008ExpressEditionを使って作られている。

VB6時代のエラー処理は「On Error」ステートメントを使うのが普通だったが、VB.NETでは「Try Catch」構文を使うのが普通で、前者は「非構造化例外処理」、後者は「構造化例外処理」と呼ばれている。(VB.NETでは「エラー」を「例外」と呼ぶ)
「構造化プログラミング」がもてはやされる現代においては、当然のごとく「構造化例外処理」が推奨されており、酢こんぶも「On Error Goto」なんて過去の遺物だと考えていた。

しかしExecSの例外処理でどうしても「非構造化例外処理」を使わざるを得なくなってしまった。orz

やりたかったのは、

「ExecSの立ち上げたプロセスが、
　子プロセスを立ち上げているかどうか検査する」

ということなのだが、これを下記の手順で実現している。

(1)現時点で動いている全プロセスのリストを取得する。
(2)For文を使って各プロセスの親プロセスを順次取得する。
(3)親プロセスがExecSの立ち上げたプロセスかどうか検査する。
(4)リストの最後まで(2)-(3)を繰り返す。

ここで問題になるのが、(1)の時点では存在していたが、(2)の時点で存在しないプロセスを処理しようとすると例外が発生する、ということだ。

通常、Windows上ではかなりの数のプロセスが立ち上がっているので(2)-(4)の処理には時間がかかる。プロセスのリストを得た時点では存在したプロセスが(2)-(4)の処理中に終了して存在しなくなるというのは珍しいことではないから、対策としては、

(a)例外が発生しないように厳密にチェックする。
(b)例外が発生することを前提にして例外処理をする。

のうちのどちらかということになるが、タイミングによっては(2)の時点で存在したプロセスが(3)の時点では存在しないという場合も考えられるから、この場合は(2)の時点で厳密にチェックしたとしても例外が発生してしまう。しかも、例外を発生させることなくプロセスが存在するかどうかを検査する方法が見つけられないのだ。(T_T)

というわけで選択肢は「例外処理をする」しか残されていない。

ところで今回の例外はFor～Nextの中で発生し、例外が発生したとしても処理を継続することが必要なわけだが、

構造化例外処理は処理の継続ができない

のだ。

「On Error Goto」を使う場合は「Resume」によってモジュール内の任意の場所に戻ることができるのだが、「Try～Catch」の場合は例外処理終了後には必ずモジュールを抜けなければならないので、For～Nextのループに戻ることができない。これでは困るので、推奨されていない「非構造化例外処理」を行なうしかなくなってしまったわけだが、もともときれいとはいえないソースで誰にも見せたくないと思っていたが、それに輪をかけて「絶対見せたくないソース」に昇格(^_^;することに、、、。

なんか今回のような例外処理は頻繁に必要になりそうな気がするのだが、「非構造化例外処理」にせざるを得ないのは酢こんぶの実力不足が原因で、世の中のプログラマの人は「構造化例外処理」で何とかしているんでしょうかね？

------------------------------------------
このブログの本店「木全屋かるた堂」もよろしくです。

・ファーストガンダムのかるた売ってます。
・ファイル整理に便利な自作ツール置いてます。
・写真(コスプレ、ポートレート、動物)公開してます。
------------------------------------------

「ExecS」を作るきっかけになったのは「QuickPar」というアプリだ。

「QuickPar」はあらかじめ作っておいたパリティファイルを使って壊れたファイルを修復するためのアプリ。酢こんぶは、Netnewsに投稿されたデータを修復したり、足りないファイルを補完したり、分割ファイルを自動的に結合したりという用途に使っているが、非常に有用で手放せないアプリのひとつだ。

とても便利な「QuickPar」だが、処理が完了してもアプリ自体が終了しないので連続実行ができず、これを解決するためにアプリのCPU使用時間が0に近くなったら終了させるという動作が可能な「ExecS」を作ったというわけだ。

そして「QuickPar」の正当な後継と言えるのが「MultiPar」。既に開発が終了している「QuickPar」と違って現在も開発が続けられ、Win7にも正式に対応している。しかも作者は日本人なので改善要求も出しやすい、、、というようにいいことずくめなのだが、、、「ExecS」では正常動作させることができないんだなあ。(T_T)

実は「MultiPar」のGUI部分はフロントエンドで、動作の実態は「Par2j」というコマンドラインアプリなのだ。「MultiPar」は修復動作を開始すると子プロセスとして「Par2j」を立ち上げる。動作の実態は「Par2j」だからCPU Timeを消費するのは「Par2j」で、この間「MultiPar」はCPU Timeを消費しなくなる。すると「ExecS」はまだ修復が完了していないのに「MultiPar」を終了してしまう。

じゃあどうしようもないのかというと、「Par2j」を「ExecS」で実行させればいいのだ。「Par2J」はコマンドラインアプリで、単体でもパリティファイルの生成や修復動作ができる。これを「ExecS」で連続実行させれば問題は解決。

で、めでたしめでたし、、、かというとそうでもない。だって「Par2j」はバッチファイルを使って連続実行することもできるので、

「ExecS」の存在意義が消滅

という事態になってしまう。(^_^;

まあ「ExecS」を使うと圧縮/解凍作業を統一的に扱うことができるので存在意義がなくなるということもないのだが、対応できないアプリが「MultiPar」以外にも存在することは確実だろう。であれば対応できるようにしたいと思うのが開発者というものだ。

そんなわけで、いろいろ苦労したものの「ExecS」を「MultiPar」のようなアプリにも対応可とすることができた。ただそのアプリが立ち上げた子プロセスがさらに子プロセス(孫プロセス)を立ち上げ、動作の実態がその孫プロセスに移ったりするとダメなのだが、この辺で妥協して近く新版を公開しようと思うます。


------------------------------------------
このブログの本店「木全屋かるた堂」もよろしくです。

・ファーストガンダムのかるた売ってます。
・ファイル整理に便利な自作ツール置いてます。
・写真(コスプレ、ポートレート、動物)公開してます。
------------------------------------------