デストラクタが例外を投げると言う事は正しくリソースを解放できないという事になるため、プログラムを続ける事が出来ない深刻な事態と言えます。
なので
- プログラムをabortなどで中止してしまう(どちらにしても続行不能なので)
- 例外を伝播させず飲み込んでしまう(続行不能な例外は飲み込んではいけない)
デストラクタで失敗が予想されるようなリソース解放は保険として書いておくだけで、通常はクライアント側が適切な手順で解放のためのメソッドを呼び出すようにすべき…と言う事でしょうか?
ちなみにデストラクタ内で例外が発生した場合、たとえ例外が発生しても全てのリソースを解放しようとするため、同時に複数の例外がアクティブになる可能性があるそうです。その場合、振る舞いは未定義になるそうです。
今、 私の携わっているお仕事は組込で動的なメモリ管理を行わないように開発しているため、関係ないのかと思ったのですが、それは単にヒープ領域のメモリを(全 体の初期化プロセスでメモリを確保した後は)動的に確保しないと言うだけで、スタック領域ではコンストラクタ、デストラクタが呼び出されるため、ある程度 関係あり、でした。
ヒープ領域で使用するステートフルなクラスとスタック領域で使用するステートレスなクラスは命名規則などで分けておくべきなのかも知れませんね。
0 件のコメント:
コメントを投稿