Никто не умеет обрабатывать ошибки

Самый частый способ обработки исключения — это alert, messagebox и друзья в UI интерфейсе пользователя + запись в лог.

Я думаю, что всё сильно зависит от реально требуемой надежности проекта. Да, все говорят, что хотят/делают «максимально надежно», но на самом деле мало кто будет тратить кучу времени на то, чтобы разобрать все возможные исключения в «сервисе для загрузки фоток». Зато в сервсие обработки платежей наверняка будет разобран каждый потенциальный чих, причем не только в виде вывода сообщения об ошибке и записи в лог.

Обработка ошибок — это в значительной степени бизнес-логика, а не что-то чисто техническое, абстрагированное от контекста. Универсального решения нет, и вряд ли оно появится.

По-моему у автора явно выраженная эксепшенофилия.

смотрите в оба и не позволяйте исключениям убивать ваше приложение.

Вот какие приложения «убиваются» эксепшенами, м? Hello world консольный? Все нормальные фреймворки предоставляют коллбэки для хэндлинга эксепшенов. О качестве вашей портянки public static class Exceptions вообще промолчу.

P.S. Отдельный приз за это:

        public static bool NotFatal(this Exception ex) {
            return fatalExceptions.All(curFatal => ex.GetType() != curFatal);
        }

        public static bool IsFatal(this Exception ex) {
            return !NotFatal(ex);
        }

Дайте угадаю, на Delphi кодили раньше, да?

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

Большая часть проблем связанных с обработкой исключений вызвана тем, что ошибки и исключения смешивают в одну кучу. Необходимо отличать одно от другого, причём ошибки нужно возвращать.

Изначально всё пошло от того, что когда появились исключения их начали использовать вместо возвращения ошибок. Основных причин было две: во-первых возврат ошибок в языках где нет удобной поддержи кортежей приводил к необходимости смешивать в возвращаемом значении два типа данных (результат и ошибку) что всегда воспринималось как не элегантный подход от которого с радостью избавились; во-вторых обработка ошибок дело нудное и сложное, а исключения дали возможность с (относительно) чистой совестью избавиться от обработки ошибок здесь и сейчас, и отложить её «на потом».

Суть исключений не в том, что ими можно сигнализировать об ошибках, и не в том, что эти ошибки можно удобно сгруппировать по классам и обрабатывать фильтруя по этим классам, а в том, что исключения раскручивают стек! Поэтому выкидывать исключения нужно только тогда, когда действительно необходима именно раскрутка стека — т.е. при возникновении критической ошибки, т.е. такой, после которой нельзя восстановиться и всё-таки как-то выполнить поставленную задачу. Все остальные, обычные ошибки необходимо обрабатывать как можно ближе к месту, где они возникли — т.е. там, где вызывалась функция в которой произошла ошибка — только в той точке, где мы для чего-то вызвали эту функцию мы можем адекватно обработать все возможные варианты ошибок и принять решение как быть дальше, раз мы не получили от этой функции нужный нам результат.

Тут возникает логичный вопрос: а как мы узнаем, критическая это ошибка или нет — ведь всё зависит от требований высокоуровневой задачи. Например, ошибка DNS для задачи выкачки url — критическая или нет? Вроде бы да… но если у нас задача выкачивать url параллельно тысячами в секунду ошибка с одной из url вряд ли действительно является критической. Правильный ответ на этот вопрос — только сама высокоуровневая задача (т.е. ваше основное приложение) знает, что для неё является критической ошибкой, а что нет.

Следствием из этого является то, что любые модули/библиотеки, по определению, не знают, в каком приложении их используют, и какие ошибки являются критическими, а какие нет. Поэтому они не должны выкидывать исключения (на самом деле это не совсем так — если в них возникают ошибки вроде out of memory или segmentation fault и им подобные — это вполне себе типичные исключения, которые можно и нужно выкидывать как исключения, а не возвращать кодами ошибок — но это типичное «исключение из правила, только подтверждающее это правило»). При этом внутри себя библиотеки вполне могут пользоваться исключениями, когда необходима именно раскрутка стека — например, в задачах рекурсивного парсинга — но все свои внутренние исключения эти библиотеки должны сами и перехватывать, а наружу возвращать обычные ошибки.

При таком подходе всё работает совершенно адекватно: все ошибки, которые можно нормально обработать, обрабатываются в том месте, где они возникли (и без излишних простыней try/catch); исключения возникают крайне редко, их очень немного, и большая их часть просто честно убивает приложение (если в приложении и есть глобальный перехват всех исключений, то он используется для попытки вывода сообщения об исключении в лог перед тем как приложение будет аварийно завершено, а не для молчаливого заглушения исключений), а явно обрабатывается очень небольшое количество вполне конкретных исключений, специфичных для вашего приложения (вроде выше упомянутых примеров, когда из-за ошибки парсинга или выкачки url необходимо прервать с раскруткой стека большой блок логики приложения).

Верно, обработка ошибок — это тоже поведение функционала. На практике бывает хватает 4 типов — отказ функционала, предупреждение о неприятном поведении, посмотрим потом, это нормально. Тогда все бросаемые исключения сводятся к этим, в зависимости от критичности функционала. Затем типы эскалируются: кому — пользователь, сисадмин, начальник, система; как — алерт, смс, ночной телефонный звонок, лог.
Фотохостингу, скажем, нерабочая загрузка котиков будет фатальна, для блога — неприятна, для банка — параллельна.

Не пойму суть проблемы:

Подкину ещё проблему: что, если вам нужно в цикле вызывать код, который всё время выбрасывает исключения в случае, если что-то не так?

Если exception обрабатывается в catch тут же, в цикле, то в цикле стек расти не будет, если в цикле только finally, то цикл и вообще весь код по стеку вызовов прервется, до того места, где это обработано в catch, стек тоже расти не будет

Начнём с версионирования, потому что тут проблемы легко увидеть. Скажем я создаю метод foo, который декларирует проброс исключений A, B и C. Во второй версии метода я хочу добавить пару фишек и теперь метод foo может выкинуть также исключение D. Добавление нового исключения является несовместимым изменением, потому что существующие пользователи этого метода почти 100% не будут ловить это исключение.

И все в команде с этим единодушно согласились… Видимо потому что никто не умел правильно готовить проверяемые исключения.

Их нужно применять лишь в том случае, когда конкретный тип исключения влияет на поведение системы. Во всех остальных случаях оборачивать в RuntimeException (не проверяемое).

Т.е. если для пользователей метода foo не важно какое из проверяемых исключений еще может быть добавлено в обновленной версии метода, то они могут оборачивать все Exception в RuntimeException. Обратите внимание! В Java системные исключения, которые наследуются от Error, что решает проблему глобального перехвата Exception как в C#.

Беда в том, что в подавляющем большинстве прикладного софта отсутствует стратегия обработки отказов (будь то исключения, коды ошибок или банальные null/NaN/undefined).
Программисты более-менее легко пишут «оптимистичную» часть кода, которая делает работу. если всё хорошо.
И с большим скрипом — пессимистичные ветки, отвечающие за различные сбои.
Да и тестировать первое намного приятнее второго — не так-то просто вызывать катаклизмы типа out of memory, database gone или там device read error для каждой относящейся к делу строки программы.
А потом у реальных юзеров shit таки happens (часто по причине действий самих юзеров, но и из-за багов в софте тоже), и среди не-программистов твердо укоренилось мнение, что все ваши программы — глючат, а компы это что-то по части магии.
Если конструктивно, то должно быть понимание, что в реальной жизни пессимистичные ветки есть и их игнорирование — это просто-напросто нереализованная часть кода.
Общая стратегия пессимистичных веток должна быть следующая:
1. Сохранить пользовательские данные, для этого откатиться на last-known-good точку. У вас нет транзакций, журнала или undo/redo? У вас плохой софт.
2. Максимально ограничить расползание сбоя на другие подсистемы, файлы, запросы, пользователей или что там у вас.
3. Восстановить целостность управляющих данных самого приложения, если возможно — вернуться в режим штатной обработки запросов, если нет — перейти в «безопасный режим» и дать юзеру возможность что-то сделать (поднять сеть, закрыть лишние программы, освободить место на диске, оживить бд и т.д.) вместо того, чтобы просто отвалиться с несохраненными данными.
Когда вот такая стратегия для конкретного приложения и конкретных видов сбоев понятна, тогда и больших проблем с обработкой ошибок не возникает, это становится просто написанием еще одной части кода.

У исключений есть еще одна беда — они замечательно раскручивают стек в случае синхронного кода, но совершенно бесполезны в случае использования колбэков или многопоточности.

Например, нам нужно собрать проект, для этого мы запускаем параллельно 3 задачи. Если хотябы одна из них упадет, то нужно остановить и другие 2, после чего завершиться с ошибкой. Исключения тут идут лесом. А если нам нужно при указании специального параметра не завершать приложение, а вывести сообщение в консоль, продолжая параллельные задачи, после чего ожидая изменения файлов, после чего запускать только те задачи, которые зависят от измененных файлов?

Исключения — это и правда зло, потому что полагаются на стек. Вместо этого хорошо иметь отдельный стек «доменов» (что-то типа nodejs.org/api/domain.html) и при создании колбэка привязывать к нему текущий домен. А в домене уже при его создании устанавливать стратегию реагирования на исключительные ситуации.

Я писал свои исключения лишь с целью отладки, чтобы проверять корректность параметров при инициализации. Язык Objective C. В основном же использую коды возврата, если в чистом C, или NSError. Что касается смешения ошибки и возвращаемого значения, то есть хорошая практика: по return возвращаем ошибку, а все значения через ссылки как аргументы. Не говоря уже о том, что и ошибку и значение вы можете завернуть в структуру и вернуть вместе ещё и с текстовым описанием.

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

Четверть сказали, что использовали что-то вроде метода проб и ошибок – отладка, тестирование, чтение логов, получения краш-дампов для того, чтобы выяснить какие исключения следует ловить.

Не знаешь что делать? Пиши в лог!

По данной проблеме, нужно понимать с чем мы работаем.

Изначально алгоритм программ строилась на основе условных переходов. Когда в языках появилась процедурной парадигмы, стали использовать процедуры и процедурные конструкции: while, for, do. Но на низком уровне они все равно трансформируются в условные переходы. Поэтому будем считать, что это наш примитив. Из набора таких примитивов строится программа.

Теперь посмотрим на исключения. Что такое исключение? А это такой же механизм для управления поведением программы, как условный переход. Но исключение в отличие от условного перехода имеет дополнительные «плюшки».

Так что требуется делать, когда процедура может вернуть исключение? Обрабатывать его или кидать наверх? В этом вопросе я полностью солидарен с мыслью из этого комментария: habrahabr.ru/post/221723/#comment_7555889

Суть в том, что все мы люди и задумки у каждого человека свои. Нетрудно представить библиотеку, в которой исключение выбрасывается даже в случае, когда вся библиотечная функция отработала без ошибок. Такое себе исключение, подтверждающее корректность исполнения. И что, выбрасывать это исключение наверх? Нет, конечно мы отработаем его здесь и сейчас. Точно так же нужно отрабатывать и другие исключения, которые могут высыпаться, но стоит всегда держать в голове смысл исключения, и продумывать, к чему халатная обработка этого исключения может привести. Является ли такое исключение критичным и стоит ли его скрыть в бизнес слое от пользователя.

ЗЫ: Уже не первый раз вижу, как сильные мира сего из мухи делают слона. Эта ваша проблема обрабатывать или не обрабатывать исключение — чистый академизм.

сорри за оффтоп. не буду в дальнейшем повторять данные ошибки.

О, я как раз недавно читал доклад о работе с ошибками. Возможно, будет интересно: www.youtube.com/watch?v=hzVECcMI8ys

Несколько замечаний:

1. StackoverflowExcpetion невозможно обработать. Пруф:

Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default. Consequently, users are advised to write their code to detect and prevent a stack overflow. For example, if your application depends on recursion, use a counter or a state condition to terminate the recursive loop. Note that an application that hosts the common language runtime (CLR) can specify that the CLR unload the application domain where the stack overflow exception occurs and let the corresponding process continue.

2. OutOfMemoryException — тоже обработать сложно. Точнее, существует две версии OOM — синхронная, которая бросается при выделении большого куска, который GC выделить не может, и асинхронная — которое может сгенерировать CLR, например, при попытке выделить новый сегмент для GC0.

3. Метод FullMessage является адским велосипедом, который не понятно зачем нужен. Вы же выводите в builder целиком объект исключения на каждой итерации. A ex.ToString будет выводить каждый раз полное исключение, включая все вложенные. Просто создайте исключение с пятком вложенных и вызовите этот метод.

4. Существует два стандартных способа фильтрации исключений: по типу в блоке catch, с помощью фильтров исключений (начиная с C# 6.0), зачем делать еще один обобщенный обработчик на основе Func-ов и как он помогает решать проблему обработки исключений, мне не ясно.