- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 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 ...
gost 11.12.2015 19:56 # +1
bormand 11.12.2015 20:27 # +3
absolut 13.12.2015 09:45 # 0
bormand 13.12.2015 09:48 # +2
Причём экспоненциально.
> никто не видит ГК
В хуёвом логировании, поедающем всю полезную инфу про исключение (которой в крестах и без этого кот наплакал), разве что...
bormand 13.12.2015 09:50 # +1
Soul_re@ver 13.12.2015 13:12 # +3
Вообще средств для нормального генерирования отчёта об ошибках в С++ нет. Приходится использовать велосипеды.
bormand 13.12.2015 15:40 # +3
3.14159265 15.12.2015 23:54 # +3
>Зато сдуру разрешили бросать любую хуйню
Да и в целом в реальном мире можно бросить любую хуйню, главное чтоб стек позволял.
1024-- 16.12.2015 00:35 # +1
Ещё и быстрее работает.
bormand 13.12.2015 15:47 # +2
Ну мешает, как бы. Ты же what можешь перегрузить в дочерних классах, и бектрейс отвалится.
В теории можно по аналогии с std::current_exception прикрутить какой-нибудь std::current_exception_backtrace...
Soul_re@ver 13.12.2015 16:45 # +1
Вот планируют в С++ добавить source_location, чтобы заменить всякие __FILE__, почему бы не добавить что-то вроде call_stack?
wvxvw 14.12.2015 09:07 # +2
Была история в ОпенЖДКей, когда они хотели (и даже вроде запилили) оптимизацию хвостовой рекурсии. Но тут возникает проблема: если код по-сути выполняется в одном и том же фрейме, как тогда описывать стек? Вобщем, вроде в Сане им тогда сказали, что это противозаконно, и они забили на это дело.
Ну и можно представить другие оптимизации, где части стека вызовов не будут выглядеть так, как может предполагать программист, и обязывать компилятор генерировать код так, чтобы он совпадал с предположениями программиста о том, как именно код выполняется - значит отказаться от этих оптмизиаций.
Soul_re@ver 14.12.2015 15:29 # +2
Так же, как его описывает дебаггер, когда ты ковыряешь прогу, собранную с -О3 -s и прочими оптимизациями. Хотя бы выдать частичную информацию, чтобы было понятно, куда копать. В стандарт, понятное дело, это не внести, разве что как "implementation-defined program state information".
guest 15.12.2015 22:57 # 0
3.14159265 15.12.2015 23:56 # +2
>если код по-сути выполняется в одном и том же фрейме, как тогда описывать стек?
Ой-ой-ой, как страшно жыдь.
>Вобщем, вроде в Сане им тогда сказали, что это противозаконно, и они забили на это дело.
Ага. А инлайн методов как-то работает, try~catch как-то превращается в goto и трейсы у всез нормальные. Жаль пацанам никто не рассказал что инлайн - это незаконно. А разгадка одна - деоптимизация.
wvxvw 16.12.2015 01:22 # 0
Я все не читал. Еще где-то встречал чистосердечное слезное признание кого-то из Сана, что в их реализации безопасности какие-то методы считали фреймы стека, ну и, соответственно, если с ними немножко поиграть, то безопасность пропадает.
3.14159265 16.12.2015 03:17 # 0
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 дуплит что стектрейс по-просту не нужен.
3_14dar 16.12.2015 22:05 # 0
bormand 17.12.2015 12:27 # +2
3_14dar 19.12.2015 02:25 # 0