ありますが、「例外処理はすべてデストラクタで行われる」って思想の言語設計なもんだからなかなか導入できない。「デストラクタってなに?それ美味しいの?」てなコードが溢れてる。手続きの実装が外部サービスを呼び出したはいいが結果が例外だった場合、できることといったら2つしかありません。進むサービスの再試行など、手続きの事後条件を満たすための必要なものをそろえて手続きを最後までやり遂げる。戻る事後条件を満たす処理が継続できないので処理を中断して呼び出し側に手続きが失敗したことを示す結果(例外)を返す。進むほうを選べるケースは限られています。サービス失敗の理由が「今は忙しいから後にして」っていう時ぐらいしかありません。場合は戻るほうを選ぶことになります。手続きが実行している途中で例外に遭遇した場合、その手続きの内部はどのような状態になっているでしょうか?カウンターが辻褄の合わない数になっているかも知れない。手続きを正常終了したとき結果を収めるメモリをアロケートした状態かもしれない。メモリ上に正常終了した結果を途中まで作成している段階かもしれない。いった中途半端な状態になっていることでしょう。このようなゴミをほったらかしにして呼び出し元に制御を戻してはいけません。広げかけた風呂敷はきちんと畳んで戻りましょう。ゴミを入力にしては、どんなに正しい処理もゴミしか産みません。これが訳の分からない不具合の原因になる。っばっぐてぇのはゴミを生み出した処理を修正することであって、ゴミをなんとか食べられるように弄り回すことなんかじゃねぇんだよ!!!!”#$%&'()orz失礼。取り乱してしまいました。エラーっていうのはこの中途半端なゴミのことです。ゴミを片付けることを、「例外によるエラーからの回復」といいます。実はエラーというのは呼び出し側の概念だったんですねぇ。失敗を報告しないのは実装側の罪それを処理しないのは呼び出し側の罪お後がよろしいようで。エラーからの回復処置は、手続きが呼び出される前の状態まで巻き戻すことが望ましい。すれば呼び出し元のほうのエラー処理が簡単になります。いえ、パフォーマンスやメモリ使用量の問題で完全に回復するのは難しいケースも多い。そんなときでも、少なくとも物事の辻褄があった状態を保たねばなりません。手続きの呼び出し元もまた、さらに外側の呼び出し元が利用するサービスを提供する手続きなわけでして、例外が発生した場合、それぞれの手続がエラー処理を実行して次々と外側の手続きへ連鎖してゆきます。メイン手続きが例外にであうとプログラムが異常終了する。理屈通り!おっと、私達が作っているのは、ユーザーと対話的に処理するプログラムでした。最後に例外を処理するのはプログラムを利用しているユーザーってことになります。“セーブできませんでした。セーブ先デバイスのイジェクトが検出されました。別のデバイスにセーブしますか?”採用情報クラウドクリエイティブスタジオではプログラマを募集しております。