1. C++ / Говнокод #19170

    −4

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    try {
        f();
    }
    catch(...) {
        std::cout << "f() throw\n";
    }
    try {
        g();
    }
    catch(...) {
        std::cout << "g() throw\n";
    }
    try {
        k();
    }
    catch(...) {
        std::cout << "k() throw\n";
    }
    // etc ...

    Запостил: absolut, 11 Декабря 2015

    Комментарии (20) RSS

    • std::cout << "shovel";
      Ответить
    • try {
          f();
          try {
              g();
              try {
                  k();
              }
              catch(...) {
                  std::cout << "k() throw\n";
              }
          }
          catch(...) {
              std::cout << "g() throw\n";
              try {
                  k();
              }
              catch(...) {
                  std::cout << "k() throw\n";
              }
          }
      }
      catch(...) {
          std::cout << "f() throw\n";
          try {
              g();
              try {
                  k();
              }
              catch(...) {
                  std::cout << "k() throw\n";
              }
          }
          catch(...) {
              std::cout << "g() throw\n";
              try {
                  k();
              }
              catch(...) {
                  std::cout << "k() throw\n";
              }
          }
      }
      Ответить
      • Это уже не говнокод, а заливающий всё вокруг фонтан поносокода. Но неужели в первичном варианте никто не видит ГК?
        Ответить
        • > заливающий
          Причём экспоненциально.

          > никто не видит ГК
          В хуёвом логировании, поедающем всю полезную инфу про исключение (которой в крестах и без этого кот наплакал), разве что...
          Ответить
          • P.S. Вот, наверное, самый бесящий момент в крестах - исключения без бектрейсов. Нихуя не понятно, откуда и почему они вылетели.
            Ответить
            • И, главное, ни один разработчик компиляторов не додумался добавить это хотя бы в what(), хотя ничто не мешает.

              Вообще средств для нормального генерирования отчёта об ошибках в С++ нет. Приходится использовать велосипеды.
              Ответить
              • Зато сдуру разрешили бросать любую хуйню, даже числа...
                Ответить
                • В js тоже так можно. Никто не жалуется.

                  >Зато сдуру разрешили бросать любую хуйню
                  Да и в целом в реальном мире можно бросить любую хуйню, главное чтоб стек позволял.
                  Ответить
                  • > В js тоже так можно.
                    Ещё и быстрее работает.
                    Ответить
              • > хотя ничто не мешает
                Ну мешает, как бы. Ты же what можешь перегрузить в дочерних классах, и бектрейс отвалится.

                В теории можно по аналогии с std::current_exception прикрутить какой-нибудь std::current_exception_backtrace...
                Ответить
                • Если я перегружаю стандартное исключение, я могу позаботиться о сохранении бектрейса, хотя бы вызовом what родителя. Починить отсутствие бектрейса в исключениях выбрасываемых стандартной библиотекой, или отсутствие любой возможности посмотреть на стек вызовов сложнее.

                  Вот планируют в С++ добавить source_location, чтобы заменить всякие __FILE__, почему бы не добавить что-то вроде call_stack?
                  Ответить
              • > хотя ничто не мешает

                Была история в ОпенЖДКей, когда они хотели (и даже вроде запилили) оптимизацию хвостовой рекурсии. Но тут возникает проблема: если код по-сути выполняется в одном и том же фрейме, как тогда описывать стек? Вобщем, вроде в Сане им тогда сказали, что это противозаконно, и они забили на это дело.

                Ну и можно представить другие оптимизации, где части стека вызовов не будут выглядеть так, как может предполагать программист, и обязывать компилятор генерировать код так, чтобы он совпадал с предположениями программиста о том, как именно код выполняется - значит отказаться от этих оптмизиаций.
                Ответить
                • >как тогда описывать стек

                  Так же, как его описывает дебаггер, когда ты ковыряешь прогу, собранную с -О3 -s и прочими оптимизациями. Хотя бы выдать частичную информацию, чтобы было понятно, куда копать. В стандарт, понятное дело, это не внести, разве что как "implementation-defined program state information".
                  Ответить
                  • В джаве так не принято, в отличии от сейц
                    Ответить
                • >Была история в ОпенЖДКей, когда они хотели
                  >если код по-сути выполняется в одном и том же фрейме, как тогда описывать стек?

                  Ой-ой-ой, как страшно жыдь.

                  >Вобщем, вроде в Сане им тогда сказали, что это противозаконно, и они забили на это дело.

                  Ага. А инлайн методов как-то работает, try~catch как-то превращается в goto и трейсы у всез нормальные. Жаль пацанам никто не рассказал что инлайн - это незаконно. А разгадка одна - деоптимизация.
                  Ответить
                  • Говорят, что тут есть вся история: http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/000331.html
                    Я все не читал. Еще где-то встречал чистосердечное слезное признание кого-то из Сана, что в их реализации безопасности какие-то методы считали фреймы стека, ну и, соответственно, если с ними немножко поиграть, то безопасность пропадает.
                    Ответить
                    • Стоит немного разобраться с механизмами оптимизации в hotspote, обычно методы прекрасно инлайнятся, но в некоторых _исключительных_ ситуациях, как-то выброс исключения происходит деоптимизация и возврат к менее оптимизированной версии кода.


                      http://www.oracle.com/technetwork/java/whitepaper-135217.html#dynamic

                      http://www.ibm.com/developerworks/library/j-jtp12214/

                      http://stackoverflow.com/questions/20522870/about-the-dynamic-de-optimization-of-hotspot


                      К слову, если кто захочет поиграть в питоноблядство: где выброс исключения НЕ является _исключительной_ ситуацией и стектрейс просто не используется, например выход из цикла.

                      То в таком случае инлайн того места где бросили и того где поймали создают единый фрейм и деоптимизации не происходит! А исключение превращается в jmp, ибо hotspot дуплит что стектрейс по-просту не нужен.
                      Ответить
                      • Чот нихуя не понял. В питоне исключение бросается в итераторе/генераторе (в методе __next__()), а ловится в foreach. Где тут один фрейм?
                        Ответить
                        • Если генератор заинлайнится в метод, где по нему бегут циклом.
                          Ответить
                          • Так бывает? или это на случай
                            try {
                                if (x)
                                    raise Exception();
                            } except (Exception) {
                                // ...
                            }
                            Ответить

    Добавить комментарий