Не смог быстро найти в гугле ответ: можно ли из функции возвращать значение из try-блока? Выглядит отвратительно, поэтому я присваиваю значение временной переменной (созданной до начала try-блока) и делаю возврат значения из функции уже после всех try-catch-finally блоков.
Вопрос возник, потому что я увидел возврат значения из try-блока в коде одного коллеги - должен ли я его править. Может быть это допустимый способ... хоть и не внушает доверие...
Полная версия этой страницы: Можно ли возвращать значение функции/метода из try-блока
Вынос значения в отдельную переменную без необходимости как раз менее очевиден и озадачивает.
Отвратительно, когда возвращают значение и из try-блока, и из finally, это действительно может запутать.
Отвратительно, когда возвращают значение и из try-блока, и из finally, это действительно может запутать.
Цитата(lost_shadow @ 01.11.2013, 13:35) 
Вынос значения в отдельную переменную без необходимости как раз менее очевиден и озадачивает.
Отвратительно, когда возвращают значение и из try-блока, и из finally, это действительно может запутать.
Отвратительно, когда возвращают значение и из try-блока, и из finally, это действительно может запутать.
Так я только потому и сделал отдельную переменную, чтобы в ней сохранять значения получаемые в try-блоке (чтобы возвратить вне try-catch-finaly). По умолчанию всё равно будет что-то возвращено. Иначе говоря, мне моя мера кажется меньшим из 2-х зол.
Возвращать результат из try блока совершенно нормально, если в catch будет rethrow (или catch нет вообще), а внутри finally только чистка ресурсов. Короче, не суть, откуда именно, главное, чтобы плюс-минус из одного контекста.
Спасибо
Ежели мне не изменяет мой склероз, то finally части в стандарте С++ нет, исключительно расширение M$.
Причём return из finally останавливает раскрутку стека в случае наличия исключения.
Т. е. я бы сильно не советовал так делать, бо изрядно неинтуитивное поведение.
А вот return из try или catch - вполне понятная и удобная конструкция.
За Objective-C - не в курсе, но для Delphi/Builder придерживался именно таких правил.
Причём return из finally останавливает раскрутку стека в случае наличия исключения.
Т. е. я бы сильно не советовал так делать, бо изрядно неинтуитивное поведение.
А вот return из try или catch - вполне понятная и удобная конструкция.
За Objective-C - не в курсе, но для Delphi/Builder придерживался именно таких правил.
Автор не уточнил что именно он под С++ понимает.
Ключевое слово finally есть в Borland C++ Builder и M$ С++/CLI.
В Builder-е конструкция базируется именно над SEH-ем, и там как раз верно моё замечание про return.
Как работает в M$ С++/CLI - я не разбирался.
Но в любом случае не советовал бы делать return из finally введу неочевидности результата.
Ключевое слово finally есть в Borland C++ Builder и M$ С++/CLI.
В Builder-е конструкция базируется именно над SEH-ем, и там как раз верно моё замечание про return.
Как работает в M$ С++/CLI - я не разбирался.
Но в любом случае не советовал бы делать return из finally введу неочевидности результата.
Дж. Рихтер в своей книге "Создание эффективных Win32-приложений" посвятил целую главу структурной обработке исключений. Позволю себе цитату:
Книга замечательная и жаль, что автор остановился где-то между Win 2000 и XP и более свежих версий нет
Цитата
В конец блока try в функции Funcenstein2 добавлен оператор retum Он сообща ет компилятору, что Вы хотите выйти из функции и вернуть значение переменной dwTemp (в данный момент равное 5). Но, если будет выполнен return, текущий поток никогда не освободит семафор, и другие потоки не получат шанса занять этот сема фор. Такой порядок выполнения грозит вылиться в действительно серьезную пробле му ведь потоки, ожидающие семафора, могут оказаться не в состоянии возобновить свое выполнение.
Применив обработчик завершения, мы не допустили преждевременного выпол нения оператора return Когда return пытается реализовать выход из блока try, компилятор проверяет, чтобы сначала был выполнен код в блоке finally, — причем до того, как оператору return в блоке try будет позволено реализовать выход из функции Вы зов ReleaseSemaphore в обработчике завершения (в функции Funcenstein2) гаранти рует освобождение семафора — поток не сможет случайно сохранить права на се мафор и тем самым лишить процессорного времени все ожидающие этот семафор потоки.
После выполнения блока finаllу функция фактически завершает работу Любой код за блоком finally не выполняется, поскольку возврат из функции происходит внутри блока try. Так что функция возвращает 5 и никогда — 9
Каким же образом компилятор гарантирует выполнение блок finally до выхода из блока try? Дело вот в чем. Просматривая исходный текст, компилятор видит, что Вы вставили return внутрь блока try Тогда он генерирует код, который сохраняет воз вращаемое значение (в нашем примере 5) в созданной им же временной перемен ной Затем создаст код для выполнения инструкций, содержащихся внутри блока finally, — это называется локальной раскруткой (local unwind) Точнее, локальная рас крутка происходит, когда система выполняет блок finаllу из-за преждевременною выхода из блока try Значение временной переменной, сгенерированной компилято ром, возвращается из функции после выполнения инструкций в блоке finаllу
Как видите, чтобы все это вытянуть, компилятору приходится генерировать допол нительный код, а системе — выполнять дополнительную работу На разных типах процессоров поддержка обработчиков завершения реализуется по-разному Напри мер, процессоруА1рhа понадобится несколько сотен или даже тысяч машинных ко манд, чтобы перехватить преждевременный возврат из try и вызвать код блока finаllу Поэтому лучше не писать код, вызывающий преждевременный выход из блока try обработчика завершения, — это может отрицательно сказаться на быстродействии программы. Чуть позже мы обсудим ключевое слово _leave, которое помогает избе жать написания кода, приводящего клокальной раскрутке.
...
Заметьте: когда поток управления выходит из блока try естественным образом (как в Funcensfetn1), издержки от вызова блока finally минимальны При использовании компилятора Microsofr на процессорах x86 для входа finаllу при нормальном выхо де из try исполняется всего одна машинная команда — вряд ли Вы заметите ее влия ние на быстродействие своей программы Но издержки резко возрастут, ссли компи лятору придется генерироватьдополнительный код, а операционной системе — вы полнять дополншельную работу, как в Funcenstetn2
Применив обработчик завершения, мы не допустили преждевременного выпол нения оператора return Когда return пытается реализовать выход из блока try, компилятор проверяет, чтобы сначала был выполнен код в блоке finally, — причем до того, как оператору return в блоке try будет позволено реализовать выход из функции Вы зов ReleaseSemaphore в обработчике завершения (в функции Funcenstein2) гаранти рует освобождение семафора — поток не сможет случайно сохранить права на се мафор и тем самым лишить процессорного времени все ожидающие этот семафор потоки.
После выполнения блока finаllу функция фактически завершает работу Любой код за блоком finally не выполняется, поскольку возврат из функции происходит внутри блока try. Так что функция возвращает 5 и никогда — 9
Каким же образом компилятор гарантирует выполнение блок finally до выхода из блока try? Дело вот в чем. Просматривая исходный текст, компилятор видит, что Вы вставили return внутрь блока try Тогда он генерирует код, который сохраняет воз вращаемое значение (в нашем примере 5) в созданной им же временной перемен ной Затем создаст код для выполнения инструкций, содержащихся внутри блока finally, — это называется локальной раскруткой (local unwind) Точнее, локальная рас крутка происходит, когда система выполняет блок finаllу из-за преждевременною выхода из блока try Значение временной переменной, сгенерированной компилято ром, возвращается из функции после выполнения инструкций в блоке finаllу
Как видите, чтобы все это вытянуть, компилятору приходится генерировать допол нительный код, а системе — выполнять дополнительную работу На разных типах процессоров поддержка обработчиков завершения реализуется по-разному Напри мер, процессоруА1рhа понадобится несколько сотен или даже тысяч машинных ко манд, чтобы перехватить преждевременный возврат из try и вызвать код блока finаllу Поэтому лучше не писать код, вызывающий преждевременный выход из блока try обработчика завершения, — это может отрицательно сказаться на быстродействии программы. Чуть позже мы обсудим ключевое слово _leave, которое помогает избе жать написания кода, приводящего клокальной раскрутке.
...
Заметьте: когда поток управления выходит из блока try естественным образом (как в Funcensfetn1), издержки от вызова блока finally минимальны При использовании компилятора Microsofr на процессорах x86 для входа finаllу при нормальном выхо де из try исполняется всего одна машинная команда — вряд ли Вы заметите ее влия ние на быстродействие своей программы Но издержки резко возрастут, ссли компи лятору придется генерироватьдополнительный код, а операционной системе — вы полнять дополншельную работу, как в Funcenstetn2
Книга замечательная и жаль, что автор остановился где-то между Win 2000 и XP и более свежих версий нет
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.