Почему выполнение переходит к концу процедуры после исключения? - PullRequest
2 голосов
/ 02 марта 2009

Когда происходит необработанное исключение во время отладки некоторого кода в любой процедуре / функции / методе, отладчик останавливается там и показывает сообщение.

Если я теперь продолжу отладку шаг за шагом, выполнение перейдет непосредственно со строки, которая создала исключение, до конца текущей процедуры (если блока finally нет).

Не лучше ли продолжить со следующей строки текущей процедуры?

Зачем переходить к концу процедуры и продолжать процедуру вызова? Это просто дизайн или есть веская причина для этого?

Ответы [ 5 ]

7 голосов
/ 02 марта 2009

Исключением является непредвиденная ситуация, поэтому обработки прекращаются.

Переход к концу процедуры является невидимым оператором finally, который освобождает любую локально «распределенную» память, например строки, интерфейсы, записи и т. Д.

Если вы хотите обработать исключение, вы должны инкапсулировать вызов, который может дать исключение, с помощью оператора try .. Кроме того, и использовать предложение «on» только для обработки того конкретного исключения, которое вы хотите обработать.

В исключении вы можете проверять переменные в отладчике, а в коде вы можете вызвать исключение снова, если это необходимо.

6 голосов
/ 02 марта 2009

В общем случае неперехваченное исключение будет выполнять скрытое "finally" в каждой функции в стеке, поскольку оно "раскручивает" до обработчика исключения. Это очищает локальные переменные в каждом стеке. В таких языках, как C ++ с парадигмой Resource Acquisition Is Initialization, это также приведет к запуску деструкторов.

В конце концов, где-то в стеке вызовов, исключение будет перехвачено обработчиком. Если нет явного, предоставленный системой, он убьет процесс, потому что что еще он может разумно сделать?

3 голосов
/ 02 марта 2009

Бросок исключения - это способ сказать «что-то неожиданное происходит. Я не знаю, как с этим справиться». В таком случае лучше не делать ничего (кроме исключения), чем пытаться продолжить, не зная, правильно ли то, что вы делаете.

В реальной жизни у вас происходит то же самое: если кто-то просит вас считать до 10 на иврите (или на каком-то другом языке, который вы не знаете), вы просто говорите, что не знаете. Вы все равно не пытаетесь.

2 голосов
/ 02 марта 2009

Я ожидаю, что он перейдет к концу процедуры, а затем перейдет к блоку исключения или, наконец, к вызывающему процессу. Это действительно продолжается в вызывающем процессе, как будто ничего не случилось? Что он использует в качестве возвращаемого значения (если это вызов функции)?

Переход к следующей строке в исходной процедуре / функции был бы очень плохой вещью - это означало бы, что код, выполняющий радикально по-разному в отладчике по сравнению с выпуском (где исключение действительно будет вызывать выйдите из этой процедуры / функции, если нет блока "исключение / окончание"). Почему отладка должна полностью игнорировать исключения?

0 голосов
/ 03 марта 2009

Нужно раскрутить стек, чтобы найти обработчик.

Я согласен, что это очень раздражающее поведение. Продолжение не вариант, но он наверняка облегчит жизнь, если отладчик будет указывать на то место, куда его бросили, с локальными переменными, которые еще не повреждены. Очевидно, что следующим шагом будет наконец скрытое, а не следующая строка.

Я просто хочу иметь возможность изучить все, что могу, о том, что вызвало это. Я просто боролся с этим не очень давно. Синтаксический анализ текста, я ЗНАЛ строка, в которой возникла ошибка, не содержала нецифровых символов (допустимые пределы означают, что случай переполнения никогда не должен возникать, это мой файл данных, все, что меня беспокоит, - это ошибки), и поэтому я не стал т обработчик исключений вокруг StrToInt - что это за ерунда о том, что он не является действительным числом ????? Да, подпрограмма не будет вызывать ее, если в буфере ничего не числовое, но в пустой строке нет ничего не числового!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...