Жаль, если ваше изучение концепции исключений закончится чтением соответствующего раздела официальной документации по вашему языку.

Изучив синтаксис конструкции try{...}catch(Exception $e){...}, узнав о возможности создавать собственные классы исключений, наследуя их от класса Exception и поверхностно осознав мощь оказавшегося в ваших руках механизма, дальше вы можете пойти по одному из двух путей:

• Начать тут же использовать исключения. Скажем, прикручивать их к системе, в которой они никогда не использовались. Или приколачивать их к проекту, в котором ООП и не пахнет. Или, что самое ужасное, пытаться использовать их повсеместно, особенно там, где это не нужно.
• Попытаться понять, где их применять, как делать это правильно, и зачем они нужны.

Некоторые вещи иногда работают не так, как подсказывает интуиция. Это утверждение можно отнести к обработке исключений в Java. Далее — ситуации и примеры кода, которые отражают некоторые имеющиеся нюансы.

Введение

Как известно, многие С-библиотеки используют обратные вызовы для обеспечения какого-либо функционала. Так поступает, например, библиотека expat для реализации SAX модели. Обратный вызов или callback используется для возможности выполнить пользовательский код на стороне библиотеки. Пока такой код не несет побочных эффектов — все нормально, но как только на арене появляется С++, все, как всегда, становится нетривиальным.

Исключения в C++ являются одним из самых серьезных механизмов языка. Предоставляя достаточно мощные возможности для анализа и обработки ошибок. Но работа с исключениями не всегда бывает такой уж удобной.

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

По служебной необходимости мне пришлось столкнуться с задачей создания клиента WCF-службы под Mono 2.6.7.
Всё вроде бы шло хорошо – клиент работал как под .NET, так и под Mono – до тех пор, пока я не занялся обработкой исключений, которые могут возникнуть в методах WCF-службы.
Проблемы начались тогда, когда мне понадобилось обработать моё собственное исключение, содержащее не только сообщение исключения, но и некоторую дополнительную информацию.
Я решил, что организую обработку исключительных ситуаций так, как это описано в статье «Exceptions through WCF» (http://habrahabr.ru/blogs/net/41638/) уважаемого Романа RomanNikitin.
В .NET клиент работал так, как надо, а вот при запуске под Mono возникла следующая ошибка:

Одним из самых замечательных и притягательных свойств языка Common Lisp является, безусловно, его система обработки исключений.

Более того, по моему, лично, мнению, подобный подход к исключениям является единственно правильным для всех императивных языков, и вот по какой простой причине:

Механизм «исключений»(или, как они называются в мире CL — conditions) в Common Lisp отделен от механизма раскрутки стека, а это, соответственно, позволяет обрабатывать любые всплывающие в программе исключительные(да и не только исключительные) ситуации прямо в том месте, где они возникли, без потери контекста выполнения программы, что влечет за собой удобство разработки, отладки, да и вообще, удобство построения логики программы.

Наверное, следует сказать, что Common Lisp Condition System, несмотря на свою уникальность в среде высокоуровневых языков программирования, очень близка известным многим разработчикам низкоуровневым средствам современных операционных систем, а именно: синхронным сигналам UNIX и, гораздо ближе, механизму SEH(Structured Exception Handling) из Windows. Ведущие реализации CL основывают такие элементы управления потоком вычислений, как механизм обработки исключений и раскрутка стека, именно на них.

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

На прошлой неделе я вместе с несколькими моими коллегами учавствовал в громкой речи о том факте, что Go обрабатывает ошибки в ожидаемых сценариях посредством возвращения кода ошибки вместо использования исключений или другого схожего механизма. Это довольно спорная тема, потому что люди привыкли избегать ошибки с помощью исключений, а Go возвращает улучшенную версию хорошо известной модели, ранее принятой несколькими языками — включая C — при которой ошибки передаются через возвращаемые значения. Это значит, что ошибки маячат перед глазами программиста и вынуждают иметь с ними дело все время. Кроме того, спор переходит в направление того факта, что в языках с исключениями каждая ошибка безо всяких дополнительных действий несет в себе полную информацию о том, что и где произошло, а это может быть полезно в некоторых случаях.

1. Особенности работы с переменными и литералами в Perl6
2. Perl6 — Операции над переменными, анонимные блоки
3. Perl6 — Условные операторы, циклы
4. Perl6 — Работа с функциями
5. Perl6 — Классы
6. Perl6 — Ввод-вывод, модули
7. Perl6 — Комментарии, пробельные символы, скобки
8. Perl6 — Перегрузка операторов
9. Perl6 — Работа с типами данных
В прошлой статье я заикнулся об отлове исключений. Немногие скрипты, что встречались с исключениями, выживали, и слишком много моих скриптов погибло от их рук. Пожалуй, настало время устроить на них охоту. Для тех кому интересно, чем же мы будет их ловить — встречаемся под катом.

Для кого написана статья

Данная статья предназначена прежде всего для новичков в мире .NET, но может быть полезна также и разработчикам с опытом, которые не до конца разобрались, как правильно строить свои user-defined exceptions с помощью C#.

Пример кода для данной статьи можно скачать здесь.

Создание простого исключения

Создавать собственные типы исключений в C# рекомендуется в тех случаях, когда нужно четко отделить возникшую в написанном программистом коде исключительную ситуацию, от исключения, возникающего в стандартных типах .NET Framework.

Сегодня Аарон Тюрон — разработчик, недавно присоединившийся к разработке Rust в Mozilla — объявил об отсрочке реализации какого-либо механизма исключений, кроме уже существующего макроса try! и типа Result, до неопределённого момента после первого релиза языка программирования Rust.

Это означает, что в Rust 1.0 будут отсутствовать исключения первого класса — то есть, полностью интегрированные с другими фичами языка.

Для обработки ошибок в данной момент в Rust существует тип Result { Ok(value), Err(why) } и макрос try!. Тип Result представляет из себя перечисление (enum), похожее на Option { Some(value), None } и связанное с ним по смыслу. Вариант None типа Option говорит об отстутствии значения, а вариант Err(why) типа Result уточняет, почему значение отсутствует.

Rust предлагает возвращать тип Result из функций, чтобы передавать значение возврата или причину, по которой значение вернуть не удалось. Макрос try! в свою очередь позволяет автоматически возвращать Err(why) из текущей функции, если вызов другой функции не удался (применяется к объекту типа Result).

В преддверии Дня программиста и по следам Дня тестировщика хочу рассказать о том как упростить жизнь и тем и другим в их общем деле — разработке и отладке ПО.
А именно — расскажу о том как сделать исключения С++ более информативными, а логирование ошибок — более компактным.

В статье рассмотрена полная интеграция C++ библиотеки в managed окружение с использованием Platform Invoke. Под полной интеграцией подразумевается возможность наследования классов библиотеки, реализации её интерфейсов (интерфейсы будут представлены в managed коде как абстрактные классы). Экземпляры наследников можно будет «передавать» в unmanaged окружение.

Любому программисту, который знаком с UEFI, известно, что встроенного механизма обработки исключений там нет. Речь идет о try/except блоках, которые являются расширением Microsoft C/C++ компиляторов. Бывает очень полезно иметь такой механизм и в полном объеме пользоваться теми плюсами, которые он дает. Поэтому в данной статье речь пойдет именно о решении этой проблемы. Также к статье прилагается полная реализация механизма с его демонстрацией на базе UEFI приложения. Затронуты только 64х битные процессоры фирмы Intel, и в обсуждении подразумеваются только они. Реализация механизма находится в папке exceptions хранилища git по адресу: https://github.com/anatolymik/machineries.git.

Ранее мы обсуждали прикладное применение механизма обработки исключений вне среды Windows. Теперь мы более подробно рассмотрим, как это работает в Windows x64. Материал будет описан последовательно, начиная с самых основ. Поэтому многое может оказаться вам знакомым, и в этом случае такие моменты можно просто пропустить.

Опираясь на материал, описанный в первой части данной статьи, мы продолжим обсуждение темы обработки исключений в Windows x64. И в этой части мы подробно рассмотрим те области PE образа, которые задействуются в процессе обработки исключений. Описываемый материал требует знания базовых понятий, таких, как пролог, эпилог, кадр функции и понимания базовых процессов, таких, как действия пролога и эпилога, передача параметров функции и возврат результата функции. Если читатель не знаком с вышеперечисленным, то перед прочтением рекомендуется ознакомиться с материалом из первой части данной статьи.

Опираясь на материал, описанный в первой и второй частях данной статьи, мы продолжим обсуждение темы обработки исключений в Windows x64.

Описываемый материал требует знания базовых понятий, таких, как пролог, эпилог, кадр функции и понимания базовых процессов, таких, как действия пролога и эпилога, передача параметров функции и возврат результата функции. Если читатель не знаком с вышеперечисленным, то перед прочтением рекомендуется ознакомиться с материалом из первой части данной статьи. Также, если читатель не знаком со структурами PE образа, которые задействуются в процессе обработки исключения, тогда перед прочтением также рекомендуется ознакомиться с материалом из второй части данной статьи.

Опираясь на материал, описанный в первой, второй и третьей частях данной статьи, мы продолжим обсуждение темы обработки исключений в Windows x64.

Описываемый материал требует знания базовых понятий, таких, как пролог, эпилог, кадр функции и понимания базовых процессов, таких, как действия пролога и эпилога, передача параметров функции и возврат результата функции. Если читатель не знаком с вышеперечисленным, то перед прочтением рекомендуется ознакомиться с материалом из первой части данной статьи. Если читатель не знаком со структурами PE образа, которые задействуются в процессе обработки исключения, тогда перед прочтением рекомендуется ознакомиться с материалом из второй части данной статьи. Также, если читатель не знаком с процессом поиска и вызова обработчиков исключений, рекомендуется ознакомиться с третьей частью данной статьи.

Задача публикации: доступно изложить способ организации иерархии исключений и их обработки в приложении. Без привязки к фреймворкам и конкретной архитектуре. Описываемый способ является де-факто стандартом в сообществе: он используется во многих серьёзных библиотеках и фреймворках. В том числе Zend, Symfony. Не смотря на его логичность и универсальность, формального описания предлагаемого подхода на русском языке я не нашёл. После неоднократного устного изложения концепции коллегам, родилась мысль оформить её в виде публикации на Хабрахабр.

В языке PHP, начиная с 5-ой версии, доступен механизм исключений. В актуальной, 7-ой, версии этот механизм был улучшен и переработан с целью единнобразной обработки разных ошибок при помощи конструкции try{} catch...

В стандартной библиотеке (SPL) PHP предоставляет готовый набор базовых классов и интерфейсов для исключений. В 7-ой версии этот набор был расширен интерфейсом Throwable. Вот диаграмма всех имеющихся в версии 7 типов (изображение — ссылка):

Привет, Хабр! Есть несколько способов проверять аргументы на правильность. Например, для проверки на null можно использовать:

1. if (!ReferenceEquals(arg, null)) throw…
2. Code Contracts: Contract.Requires(!ReferenceEquals(arg, null))
3. Guard.IsNotNull(arg, nameof(arg))

В статье я рассмотрю только третий вариант (все примеры кода — для C#, однако некоторые из них будут полезны и в Java).

В прошлый раз я разобрал два примера (раз, два), как можно перейти от императивной валидации входных значений к декларативной. Второй пример действительно «слишком много знает» про аспекты хранения и имеет подводные камни (раз, два). Альтернатива – разбить валидацию на 3 части:

1. Модел байндинг: ожидали int, пришел string – возвращаем 400
2. Валидация значений: поле email, должно быть в формате your@mail.com, а пришло 123Petya – возвращаем 422
3. Валидация бизнес-правил: ожидали что корзина пользователя активна, а она в архиве. Возвращаем 422

К сожалению стандартный механизм байндинга ASP.NET MVC не различает ошибки несоответствия типа (получили string вместо int) и валидаци, поэтому если вы хотите различать 400 и 422 коды ответа, то придется это сделать самостоятельно. Но речь не об этом.

Как слой бизнес-логики может вернуть в контроллер сообщение об ошибке?

Самый распространенный по мнению Хабра способ (раз, два, три) – выбросить исключение. Таким образом между понятием «ошибка» и «исключение» ставится знак равно. Причем «ошибка» трактуется в широком смысле слова: это не только валидация, но и проверка прав доступа и бизнес-правил. Так ли это? Является ли любая ошибка «исключительной ситуацией»? Если вы когда-нибудь сталкивались с бухгалтерским или налоговым учетом, то наверняка знаете, что существует специальный термин «корректировка». Он означает, что в прошлом отчетном периоде были поданы неверные сведения и их необходимо исправить. То есть в сфере учета, без которой бизнес не может существовать в принципе, ошибки – объекты первого класса. Для них введены специальные термины. Можно ли назвать их исключительными ситуациями? Нет. Это нормальное поведение. Люди ошибаются. Программисты — просто чересчур оптимистичный народ. Мы просто никогда не снимаем розовых очков.