Сообщение Re[3]: Другой взгляд на исключения от 25.11.2015 22:10
Изменено 25.11.2015 22:12 Evgeny.Panasyuk
Здравствуйте, alex_public, Вы писали:
_>>>то в итоге это становится даже менее удобно чем древние коды возврата (особенно если в языке реализована удобная работа с кортежами и типами реализующими концепцию монады maybe), из-за непрерывных убогих try/catch на каждом углу.
EP>>Не припомню чтобы кто-то из сторонников исключений выступал за использование "try/catch на каждом углу".
_>А оно автоматом возникает в случае применения исключений не только для критических сбоев. Потому как в таком случае обработка ошибки происходит не где-то на высоком уровне, а почти всегда на уровне вызова функции, кидающей исключения. В предыдущих темах я уже приводил примеры на эту тему.
Я об этом и говорю, не припомню чтобы сторонники исключений агитировали за использование их в тех случаях, где обработка происходит на том же уровне.
Есть конечно неоднозначные случаи, где аргументация сильна и за тот и за другой вариант (в смысле исключения или return code) — но это всё же редкость. И тут, кстати, частично помогает expected<T> и аналоги.
EP>>Подобное неудобство было бы и при кодах возврата. Да и вообще, там не "про неудобство классического подхода" в целом, а лишь о нескольких конкретных use-case'ах, которые разгуливаются несколькими дополнениями в язык, которые кардинально не меняют "классический подход", а лишь дополняют его в нескольких случаях.
_>Дело в том, что при применение исключений везде, этот случай становится как раз самым распространённым.
Какой? scope(failure/success)? Посмотри например как часто они применяются в библиотеке D Phobos и в каких контекстах — то есть там где они присутствуют из коробки.
_>Вот к примеру ошибка при невозможности сохранить файл
Файл это не самый распространённый случай. Самый распространённый это выделение памяти, причём deallocate не фейлится.
_>- она должна обрабатываться с помощью исключений или же нет? )
Зависит от контекста.
_>И если с помощью исключений, то каким подходом лучше? )
Самый ванильный это ручное проставление .flush_may_throw() в конце scope (по сути это аналог scope guard).
Альтернативные варианты подробно описывал тут
Но, опять таки, это не столько относится к исключениям как к подходу в целом, а скорее к одной из реализаций.
_>>>то в итоге это становится даже менее удобно чем древние коды возврата (особенно если в языке реализована удобная работа с кортежами и типами реализующими концепцию монады maybe), из-за непрерывных убогих try/catch на каждом углу.
EP>>Не припомню чтобы кто-то из сторонников исключений выступал за использование "try/catch на каждом углу".
_>А оно автоматом возникает в случае применения исключений не только для критических сбоев. Потому как в таком случае обработка ошибки происходит не где-то на высоком уровне, а почти всегда на уровне вызова функции, кидающей исключения. В предыдущих темах я уже приводил примеры на эту тему.
Я об этом и говорю, не припомню чтобы сторонники исключений агитировали за использование их в тех случаях, где обработка происходит на том же уровне.
Есть конечно неоднозначные случаи, где аргументация сильна и за тот и за другой вариант (в смысле исключения или return code) — но это всё же редкость. И тут, кстати, частично помогает expected<T> и аналоги.
EP>>Подобное неудобство было бы и при кодах возврата. Да и вообще, там не "про неудобство классического подхода" в целом, а лишь о нескольких конкретных use-case'ах, которые разгуливаются несколькими дополнениями в язык, которые кардинально не меняют "классический подход", а лишь дополняют его в нескольких случаях.
_>Дело в том, что при применение исключений везде, этот случай становится как раз самым распространённым.
Какой? scope(failure/success)? Посмотри например как часто они применяются в библиотеке D Phobos и в каких контекстах — то есть там где они присутствуют из коробки.
_>Вот к примеру ошибка при невозможности сохранить файл
Файл это не самый распространённый случай. Самый распространённый это выделение памяти, причём deallocate не фейлится.
_>- она должна обрабатываться с помощью исключений или же нет? )
Зависит от контекста.
_>И если с помощью исключений, то каким подходом лучше? )
Самый ванильный это ручное проставление .flush_may_throw() в конце scope (по сути это аналог scope guard).
Альтернативные варианты подробно описывал тут
Автор: Evgeny.Panasyuk
Дата: 17.11.15
и тутДата: 17.11.15
Автор: Evgeny.Panasyuk
Дата: 27.09.12
.Дата: 27.09.12
Но, опять таки, это не столько относится к исключениям как к подходу в целом, а скорее к одной из реализаций.
Re[3]: Другой взгляд на исключения
Здравствуйте, alex_public, Вы писали:
_>>>то в итоге это становится даже менее удобно чем древние коды возврата (особенно если в языке реализована удобная работа с кортежами и типами реализующими концепцию монады maybe), из-за непрерывных убогих try/catch на каждом углу.
EP>>Не припомню чтобы кто-то из сторонников исключений выступал за использование "try/catch на каждом углу".
_>А оно автоматом возникает в случае применения исключений не только для критических сбоев. Потому как в таком случае обработка ошибки происходит не где-то на высоком уровне, а почти всегда на уровне вызова функции, кидающей исключения. В предыдущих темах я уже приводил примеры на эту тему.
Я об этом и говорю, не припомню чтобы сторонники исключений агитировали за использование их в тех случаях, где обработка происходит на том же уровне.
Есть конечно неоднозначные случаи, где аргументация сильна и за тот и за другой вариант (в смысле исключения или return code) — но это всё же редкость. И тут, кстати, частично помогает expected<T> и аналоги.
EP>>Подобное неудобство было бы и при кодах возврата. Да и вообще, там не "про неудобство классического подхода" в целом, а лишь о нескольких конкретных use-case'ах, которые разгуливаются несколькими дополнениями в язык, которые кардинально не меняют "классический подход", а лишь дополняют его в нескольких случаях.
_>Дело в том, что при применение исключений везде, этот случай становится как раз самым распространённым.
Какой? scope(failure/success)? Посмотри например как часто они применяются в библиотеке D Phobos и в каких контекстах — то есть там где они присутствуют из коробки.
_>Вот к примеру ошибка при невозможности сохранить файл
Файл это не самый распространённый случай. Самый распространённый это выделение памяти, причём deallocate не фейлится.
_>- она должна обрабатываться с помощью исключений или же нет? )
Зависит от контекста.
_>И если с помощью исключений, то каким подходом лучше? )
Самый ванильный это ручное проставление .flush_may_throw() в конце scope (отдалённо напоминающее scope guard).
Альтернативные варианты подробно описывал тут
Но, опять таки, это не столько относится к исключениям как к подходу в целом, а скорее к одной из реализаций.
_>>>то в итоге это становится даже менее удобно чем древние коды возврата (особенно если в языке реализована удобная работа с кортежами и типами реализующими концепцию монады maybe), из-за непрерывных убогих try/catch на каждом углу.
EP>>Не припомню чтобы кто-то из сторонников исключений выступал за использование "try/catch на каждом углу".
_>А оно автоматом возникает в случае применения исключений не только для критических сбоев. Потому как в таком случае обработка ошибки происходит не где-то на высоком уровне, а почти всегда на уровне вызова функции, кидающей исключения. В предыдущих темах я уже приводил примеры на эту тему.
Я об этом и говорю, не припомню чтобы сторонники исключений агитировали за использование их в тех случаях, где обработка происходит на том же уровне.
Есть конечно неоднозначные случаи, где аргументация сильна и за тот и за другой вариант (в смысле исключения или return code) — но это всё же редкость. И тут, кстати, частично помогает expected<T> и аналоги.
EP>>Подобное неудобство было бы и при кодах возврата. Да и вообще, там не "про неудобство классического подхода" в целом, а лишь о нескольких конкретных use-case'ах, которые разгуливаются несколькими дополнениями в язык, которые кардинально не меняют "классический подход", а лишь дополняют его в нескольких случаях.
_>Дело в том, что при применение исключений везде, этот случай становится как раз самым распространённым.
Какой? scope(failure/success)? Посмотри например как часто они применяются в библиотеке D Phobos и в каких контекстах — то есть там где они присутствуют из коробки.
_>Вот к примеру ошибка при невозможности сохранить файл
Файл это не самый распространённый случай. Самый распространённый это выделение памяти, причём deallocate не фейлится.
_>- она должна обрабатываться с помощью исключений или же нет? )
Зависит от контекста.
_>И если с помощью исключений, то каким подходом лучше? )
Самый ванильный это ручное проставление .flush_may_throw() в конце scope (отдалённо напоминающее scope guard).
Альтернативные варианты подробно описывал тут
Автор: Evgeny.Panasyuk
Дата: 17.11.15
и тутДата: 17.11.15
Автор: Evgeny.Panasyuk
Дата: 27.09.12
.Дата: 27.09.12
Но, опять таки, это не столько относится к исключениям как к подходу в целом, а скорее к одной из реализаций.