並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 8 件 / 8件

新着順 人気順

例外安全の検索結果1 - 8 件 / 8件

  • 例外安全と例外中立 - Qiita

    現代のC++で例外安全問題を抜きにして、障害に強い強固なコードを書くことはほとんど不可能に近い。以上。 Hurb Sutter [1] 例外処理における目的は、例外の回復と例外の通知の大きく2つあります。残念ながら例外の回復はとても難しく、場合によってはそもそも不可能だったりします。その場合、例外が発生したことをより上位のレイヤーに通知する事で例外処理を託します。この時、例外の通知を受け取った側は何を前提に例外の回復を行えばよいでしょうか。例外の発生によってデータ整合性は崩れてしまっているかもしれません。通知を受け取った上位レイヤーはあらゆる状態を想定して例外の回復を試みなければならないのでしょうか。もしそうだとすれば、ただでさえ難しい例外の回復がいよいよもって現実的ではなくなってしまいます。 明らかに上位レイヤーが持つべき前提条件が存在します。これは例外を通知する側が満たすべき保証と言い

      例外安全と例外中立 - Qiita
    • 例外安全 - プログラミング言語 D (日本語訳)

      例外安全なプログラミングとは、 例外を投げる可能性があるコードが実際に例外を投げた場合に、 プログラムの状態が壊れずリソースもリークしないように作るプログラミングのことを言います。 これを正しく実現するには、既存の方法では、複雑で読みにくく脆いコード を書かねばなりませんでした。結果として、例外安全性に関して バグが残っていることが非常に多かったり、そもそも手間を省くために 例外安全が完全に無視されたりしてきました。 例として、数行の文を実行するあいだMutexをロックして、 終わったら解放するというケースを考えてみましょう: void abc() { Mutex m = new Mutex; lock(m); // mutexをロック foo(); // 処理を行う unlock(m); // mutexをアンロック } >foo() が例外を投げると、abc() は例外による巻き戻しで

      • 例外安全とか幻想

        NyaRuRu @NyaRuRu InitializeCriticalSection APIの悪名高い超仕様,「空きメモリが超少ないとSTATUS_NO_MEMORY例外出しちゃうよ」はVistaで根絶に成功してたんだな.偉い. http://bit.ly/dv3Wzl

          例外安全とか幻想
        • 例外安全への道 - Road to Exception Safety | TECHSCORE BLOG | TECHSCORE BLOG

          こんにちは、鈴木です。 「例外安全 (Exception Safety)」という言葉をご存知でしょうか。 週末、本の整理をしていたときに「Exceptional C++」という本が出てきました。C++ のイディオム集といった感じの本なのですが、その中に登場する「例外安全」という言葉をご紹介します。 「例外安全」とは、例外が発生したときに適切に処理されることを意味する言葉です。「適切に」とは、リソースリークが発生しないことや、オブジェクトの内部状態の整合性が保たれるということです。 「普段から意識してるよ」という方もいると思いますが、「聞いたことが無かった」という方は、例外安全という考え方を意識することで、今までより品質の良いコードを書けるようになるはずです。 Web上のリソースでは、以下のページに記載があります。 Exception-Safety in Generic Components

          • 例外安全 - プログラミング言語 D (日本語訳)

            例外安全なプログラミングとは、 例外を投げる可能性があるコードが実際に例外を投げた場合に、 プログラムの状態が壊れずリソースもリークしないように作るプログラミングのことを言います。 これを正しく実現するには、既存の方法では、複雑で読みにくく脆いコード を書かねばなりませんでした。結果として、例外安全性に関して バグが残っていることが非常に多かったり、そもそも手間を省くために 例外安全が完全に無視されたりしてきました。 例として、数行の文を実行するあいだMutexをロックして、 終わったら解放するというケースを考えてみましょう: void abc() { Mutex m = new Mutex; lock(m); // mutexをロック foo(); // 処理を行う unlock(m); // mutexをアンロック } >foo() が例外を投げると、abc() は例外による巻き戻しで

            • threadの利用と例外安全(その1) - yohhoyの日記

              C++11標準ライブラリとBoost.Threadライブラリ(Boost 1.48.0)に含まれる、threadオブジェクトのデストラクタの振る舞いと例外安全に関するメモ。 2020-12-02追記:C++2a(C++20)標準ライブラリでは、デストラクタで自動的にjoinを呼び出すstd::jthreadが追加される。std::thread動作はC++11時点と同一。 2013-02-05追記:Boost.Thread 1.50.0〜1.56.0では記事内容に関する破壊的変更が行われる。id:yohhoy:20120206 も参照のこと。 std::threadとboost::threadのデストラクタは、それぞれ下記の動作を行う。C++0xドラフト段階ではstd::threadもboost::threadと同じ動作仕様だったが、N2802の指摘をうけてC++11標準ライブラリの仕様に変

                threadの利用と例外安全(その1) - yohhoyの日記
              • PHPを例外安全にするためのイディオム - Qiita

                (例外安全ネタでもう少し長い記事が書きたいんだけど、思いつきだけまとめておく) PHPにはアトミックでない関数が結構ある。本来1つの処理だったものが複数に分かれているような関数。終了する方の関数を呼ばずにいると、変な状態のままになってしまう。 fopen/fclose flock(LOCK_EX)/flock(LOCK_UN) PDO::beginTransaction / PDO::commit / PDO::rollback ob_start / ob_get_clean こういったものは気をつけて書かないと終了の関数だけが実行されず、例外安全を破ってしまう。 どうすれば「気をつけて書いている」ことになるのか考えてみた。 finallyを都度書く finallyを使えば、例外が起きても終了処理が呼ばれる。とりあえず、これで例外安全にはなる。 ob_start(); try { // 例

                  PHPを例外安全にするためのイディオム - Qiita
                • [C++]例外安全、new について

                  C++ では new をすると、operator new, operator delete でも実装していない限りは、必ず delete をする必要があります。 // 例外安全でないプログラム Hoge* pHoge = new Hoge(); // pHoge を使ってごにょごにょする ... delete pHoge; 普通に new をして領域を確保し、必要が無くなれば delete をするだけのプログラムです。 が、これだけでは必ず delete が出来るという保証はないのです。 これは例外について対処が出来ていなくて、pHoge を使っている途中に例外が発生した場合、pHoge は解放される機会を失い、メモリリークを引き起こします。 なので、次のように書く必要があります。 // 例外安全なプログラム Hoge* pHoge = new Hoge(); try { // pHoge

                  1