第３２章 プログラミング（３）
第３２章 プログラミング（３）
第１話 章の始めに
何故、僕が頭の中を空っぽにしたいのか？
理由があります。
① 渦巻いている？頭の中を整理するため
② トラウマを見つけ出すため
③ 空っぽに出来るか？確認するため
④ ③は無理だと思いますが、出来たとしたら何が残るのか知るため
第２話 ハミルトン閉路問題
どうやら、僕がこの問題の命題を完全に理解する事は、難しそうです。
「ＴＳＰのエッジに重みがない問題」
として、考えたいと思います。
そうすると、２８章と２９章で述べた手法で解けるのでは？
と、思います。
但し、２８章と２９章で述べた手法が有益か？否か？は、確認出来ません。
僕に出来るのは、プログラムを作成し、有益か？否か？を解析する事だけです。
しかし、それをすると、頭の中が膨らんでしまいます。
現状では、出来そうにありません。
１つ、閉路の可否を判定する方法として、僕の手法の中で、
「兄弟木が存在し、Ｃ集合（Ｘ集合も？）が無い時、閉路は無い」
と、言えます。
第３話 マクロ
システムの構築で、最も困難なのは、作った後だと思っています。
つまり、不具合が発生し、客先対応を迅速に行う事です。
通常、ログをソースの中に埋め込みます。
僕は、ほとんどの（おそらく全て）ログ・コードをサブルーチンのＲｅｔｕｒｎの
部分に埋め込みました。
全てのサブルーチンに埋め込みました。
その方法について述べたいと思います。
① サブルーチンの全てにユニークＩＤを付ける。
② サブルーチンの先頭と最後の部分にマクロ・コードを記述する。
③ 最後のマクロ・コードの頭にラベルを付ける。
④ サブルーチンの途中でＲｅｔｕｒｎしない。ラベルへＧｏｔｏ文を記述する。
⑤ ④の時、サブルーチン内でユニークなステップＩＤを付ける。
⑥ 最後のマクロ・コードの中で、エラー判定をする。
⑦ エラーの時、ログにサブルーチンＩＤとステップＩＤを掃き出す。
この方法で、何処でエラーが起こったか分かります。
この影響でオーバーヘッドが出る可能性があります。
僕の経験では、多くの場合影響はありませんでした。
さて、マクロの中身です。
先頭のマクロには、サブルーチンＩＤを設定します。
最後のマクロには、エラー判定を記述します。
そして、オーバーヘッドがこのマクロの影響の時、マクロの中身を空にします。
マクロの中身は、Ｉｎｃｌｕｄｅ文の中で記述します。
つまり、全てのサブルーチンで定型のエラー処理が行われます。
エラーの種類を分けます。
基本的に、
① 致命的エラー（Ｆａｔａｌ）：システムを停止します。
② システム続行不可能エラー：システムを停止します。
③ システム続行可能エラー（警告、注意）：システムを続行します。
システムが機械を動かしている時、①②のケースでシステムを続行すると、
機械を壊す可能性があります。
機械にエマージェンシーを送る必要があるかもしれません。
機械にエマージェンシーを送れない可能性もあります。
送る前にシステムが暴走した時です。
次章で開発者の予期せぬエラーの１つである例外について述べたいと思います。
