Да, не рекомендуется, однако Enterpise Framework раздел обработки исключений построен именно на политиках, по сути, фильтрационных. Ну, там несколько посложнее, но суть та же.
Посмотрел. Таким образом, вы согласны, что простых, не приносящих боли способов работы с ошибками нет? Вы также согласны с тем, что и исключения и коды ошибки имеют право на жизнь? Или вы исключительно за использование исключений (извиняюсь за каламбур)? А если вы считаете что нужно использовать только исключения, то какие контр-аргументы вы можете привести против того, что писал в комментариях powerman?
Вот именно! А у Сергея в статье «всё прекрасно» и «просто». Чувства боли совсем не возникает и это негативно отражается на сознании начинающих разрабов.
Это именно та статья, которая явилась одной из причин по которой я решил написать эту статью. Я, как вы уже поняли, не считаю исключения панацеей. Да и как вы уже, наверное, поняли, мало кто так считает из числа программистов реальных сложных приложений.
У меня возникла потребность написать статью, поскольку до меня дошло по сути то, что вы пытаетесь объяснить в комментариях. И мне потребовалось всё это закрепить на бумаге.
Возможно, я где-то, что-то неправильно сформулировал, это может быть.
К сожалению, далеко не всегда метод, в котором возникает ошибка способен сам что-то предпринять, поэтому приходится возвращать ошибку на уровень выше.
Ещё момент. Выкидывать исключения из библиотек именно в плане указания того, что библиотекой пользуются неправильно — хорошая практика. Это легко и просто отлаживать. Программисту остаётся только добиться того, чтобы таких исключений никогда не возникало (этих «защитных» исключений, которые защищают инварианты класса). Этого помогают добиться юнит-тесты и всякие разные практики.
Не совсем. Если случится StackOverflow и он попадёт в catch(Exception), то он съестся. После этого программа будет некоторое кол-во времени (неизвестное) будет находиться а работе и что случится с данными никому неизвестно. Это важно. Кроме означенных исключений есть ещё некоторые, которые лучше не ловить. Если вы глянете в Enterprise Framework, вы увидите примерно такой же подход — фильтрацию.
Абсолютно согласен. Так всё и есть. И баги компенсируются ручной работой, зачастую. Насколько это приятно клиенту и самому разработчику — отдельный вопрос (но я думаю всем всё очевидно).
Это программисты на books.ru угорают, называя CSharp СFail-ом?)))
Кроме всего прочего, лично Мартину вопрос задавал по поводу исключений и кодов возврата.
Возможно, я где-то, что-то неправильно сформулировал, это может быть.
Не хочу давить на экспертократию, но даже Липперт и Хэйлсберг подтвеждают наличие проблем.
К сожалению, далеко не всегда метод, в котором возникает ошибка способен сам что-то предпринять, поэтому приходится возвращать ошибку на уровень выше.
Ещё момент. Выкидывать исключения из библиотек именно в плане указания того, что библиотекой пользуются неправильно — хорошая практика. Это легко и просто отлаживать. Программисту остаётся только добиться того, чтобы таких исключений никогда не возникало (этих «защитных» исключений, которые защищают инварианты класса). Этого помогают добиться юнит-тесты и всякие разные практики.
Нет, на делфи не программировал. А что не так с этими методами?