- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 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 ...
Причём экспоненциально.
> никто не видит ГК
В хуёвом логировании, поедающем всю полезную инфу про исключение (которой в крестах и без этого кот наплакал), разве что...
Вообще средств для нормального генерирования отчёта об ошибках в С++ нет. Приходится использовать велосипеды.
>Зато сдуру разрешили бросать любую хуйню
Да и в целом в реальном мире можно бросить любую хуйню, главное чтоб стек позволял.
Ещё и быстрее работает.
Ну мешает, как бы. Ты же what можешь перегрузить в дочерних классах, и бектрейс отвалится.
В теории можно по аналогии с std::current_exception прикрутить какой-нибудь std::current_exception_backtrace...
Вот планируют в С++ добавить source_location, чтобы заменить всякие __FILE__, почему бы не добавить что-то вроде call_stack?
Была история в ОпенЖДКей, когда они хотели (и даже вроде запилили) оптимизацию хвостовой рекурсии. Но тут возникает проблема: если код по-сути выполняется в одном и том же фрейме, как тогда описывать стек? Вобщем, вроде в Сане им тогда сказали, что это противозаконно, и они забили на это дело.
Ну и можно представить другие оптимизации, где части стека вызовов не будут выглядеть так, как может предполагать программист, и обязывать компилятор генерировать код так, чтобы он совпадал с предположениями программиста о том, как именно код выполняется - значит отказаться от этих оптмизиаций.
Так же, как его описывает дебаггер, когда ты ковыряешь прогу, собранную с -О3 -s и прочими оптимизациями. Хотя бы выдать частичную информацию, чтобы было понятно, куда копать. В стандарт, понятное дело, это не внести, разве что как "implementation-defined program state information".
>если код по-сути выполняется в одном и том же фрейме, как тогда описывать стек?
Ой-ой-ой, как страшно жыдь.
>Вобщем, вроде в Сане им тогда сказали, что это противозаконно, и они забили на это дело.
Ага. А инлайн методов как-то работает, try~catch как-то превращается в goto и трейсы у всез нормальные. Жаль пацанам никто не рассказал что инлайн - это незаконно. А разгадка одна - деоптимизация.
Я все не читал. Еще где-то встречал чистосердечное слезное признание кого-то из Сана, что в их реализации безопасности какие-то методы считали фреймы стека, ну и, соответственно, если с ними немножко поиграть, то безопасность пропадает.
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 дуплит что стектрейс по-просту не нужен.