Я знаком с дюжиной языков программирования, которые в некотором роде имеют исключения, но я стал свидетелем двух «патологических» тенденций.

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

2. Исключения, определенные языком, очень редко используются пользовательскими программами. Обычно бывают одно или два популярных исключения (например, «не реализовано»). Хотя в большинстве случаев программисты создают свои собственные исключения. (Сравните это, например, с созданием новых числовых типов или новых типов коллекций).

Это выглядит как ужасное упущение для меня. Почему никто не знает, какие ошибки будут нужны в пользовательских программах? Я надеялся, что будет какая-то хорошая иерархия, похожая на числовые типы, коллекции, объектную систему и т. Д.

Что еще хуже, Goolge и Wikipedia предоставляют очень небольшую помощь по этому вопросу. Пока что я нашел только статью о функциональном исключении, которая открывается в отрывке:

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

(Функциональная теория исключений, Майк Спиви, 1988)

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

Вопрос:

Есть ли теория исключений? Если так, то как это называется? Каковы, если таковые имеются, краеугольный камень работы с изложением основы этого?

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

• Б. Рэнделл, Структура системы для отказоустойчивости программного обеспечения.
• Дж. Б. Гуденоф. Обработка исключений: проблемы и предлагаемые обозначения.
• Дж. Б. Гуденоф. Структурная обработка исключений.
• Б. Г. Райдер, М. Л. Соффа, Влияние на дизайн обработки исключений.
• Д. Теллер, А. Спивак, Т. Вароко, поймай меня, если сможешь: На пути к безопасному типу, иерархическому, легкому, полиморфному и эффективному управлению ошибками в OCaml.
• X. Leroy, F. Pessaux, Основанный на типе анализ необученных исключений.
• Р. Миллер, А. Трипати, Проблемы обработки исключений в объектно-ориентированных системах.
• С. Дрю, К.Дж. Гоф, Дж. Ледерманн, Реализация обработки исключений с нулевыми накладными расходами.
• Б. Страуструп, Исключительная безопасность: концепции и методы.
• D. Malayeri, J. Aldrich, Спецификации практических исключений.
• Х. Накано, Конструктивная формализация механизма ловли и броска.
• А. Наневский, Модальное исчисление для обработки исключений.
• П. де Гроот, Простое исчисление обработки исключений.
• H. Thielecke, Об исключениях и продолжениях в присутствии государства.
• JG Riecke, H. Thielecke, Типизированные исключения и продолжения не могут макроэкспрессировать друг друга.
• M. van Dooren, E. Steegmans. Объединение надежности проверяемых исключений с гибкостью непроверенных исключений с помощью объявлений привязанных исключений.
• JA Vaughan, Логическая интерпретация исключений в стиле Java.
• С. Марлоу, С. Пейтон Джонс, А. Моран, Асинхронные исключения в Хаскелле.
• B. Jacobs, F. Piessens, Failboxes: Обеспечиваемая безопасная обработка исключений.

Я не знаю, есть ли теория, но может появиться прагматическая экспериментальная наука.

Лучший источник, о котором я могу думать, это Бьярн Страуструп, «Дизайн и эволюция C ++», Addison-Wesley, 1994 . Если я правильно помню (это очень хорошая книга, и люди продолжают заимствовать ее у меня, а не возвращают, поэтому у меня нет копии в данный момент), есть глава об исключениях. Комитет C ++ при Страуструпе потребовал много эмпирических доказательств того, что предложенная функция была необходима, прежде чем они захотели добавить ее в определение языка. На странице Википедии об исключениях есть следующая цитата из этой книги:

На совещании в Пало-Альто [стандартизация C ++] в ноябре 1991 года мы услышали блестящее резюме аргументов в пользу семантики терминации, основанных как на личном опыте, так и на данных Джима Митчелла (из Sun, ранее из Xerox PARC). Джим использовал обработку исключений на полдюжине языков в течение 20 лет и был одним из первых сторонников семантики возобновления в качестве одного из главных разработчиков и разработчиков системы Xerox Cedar / Mesa. Его сообщение было прекращение предпочтительнее возобновления; это не вопрос мнения, а вопрос многолетнего опыта. Возобновление соблазнительно, но не актуально. Он подкрепил это утверждение опытом из нескольких операционных систем. Ключевым примером был Cedar / Mesa: он был написан людьми, которые любили и использовали возобновление, но после десяти лет использования, в системе с полмиллиона строк было только одно использование возобновления - и это был контекстный запрос. Поскольку возобновление фактически не было необходимо для такого контекстного запроса, они удалили его и обнаружили значительное увеличение скорости в этой части системы. В каждом случае, когда возобновление было использовано, оно - в течение десяти лет - становилось проблемой, и его заменял более подходящий дизайн. По сути, каждое использование возобновления представляло собой неспособность разделить отдельные уровни абстракции. В каждом случае, когда возобновление было использовано, оно - в течение десяти лет - становилось проблемой, и его заменял более подходящий дизайн. По сути, каждое использование возобновления представляло собой неспособность разделить отдельные уровни абстракции. В каждом случае, когда возобновление было использовано, оно - в течение десяти лет - становилось проблемой, и его заменял более подходящий дизайн. По сути, каждое использование возобновления представляло собой неспособность разделить отдельные уровни абстракции.

В C ++ реальным выигрышем является RAII , который значительно облегчает обработку освобождения ресурсов во время ошибок. (Это не избавляет от необходимости throwи try- catch, но это означает, что вам не нужно finally.)

Я думаю, что то, что убедило их в том, что им нужны исключения, - это общие контейнеры: средство записи контейнеров ничего не знает о видах ошибок, которые должны возвращаться содержащимися объектами (тем более о том, как их обрабатывать), но о коде, который вставил эти объекты в Контейнер должен знать что-то об интерфейсе этих объектов. Но поскольку мы ничего не знаем о том, какие ошибки могут генерировать содержащиеся объекты, мы не можем стандартизировать типы исключений. (Контрапозитивно: если бы мы могли стандартизировать типы исключений, то нам не понадобились бы исключения.)

Другая вещь, которую люди, кажется, усвоили за эти годы, состоит в том, что спецификации исключений трудно правильно вставить в язык. См. Например это: http://www.gotw.ca/publications/mill22.htm или это: http://www.gotw.ca/gotw/082.htm . (И это не только C ++, Java-программисты также имеют длинные аргументы о своем опыте с проверенными и непроверенными исключениями .)

Немного об истории исключений. Классическая статья: Джон Б. Гуденоф: «Обработка исключений: проблемы и предлагаемые обозначения», Commun. ACM 18 (12): 683-696, 1975. Но исключения были известны до этого. Они были у Месы примерно в 1974 году, и, возможно, они были у PL / I. У Ады был механизм исключений до 1980 года. Я полагаю, что на исключения C ++ больше всего повлиял опыт работы с языком программирования CLU Барбары Лисков примерно с 1976 года. Барбара Лисков: «История CLU», « История языков программирования» - II , Томас Дж. Бергин-младший и Ричард Г. Гибсон-младший (ред.). С. 471-510, ACM, 1996 .

Позвольте мне просто указать, что исключения являются случаем вычислительного эффекта . Другими вычислительными эффектами являются изменяемое состояние, ввод-вывод, недетерминизм, продолжения и многие другие. Таким образом, ваш вопрос можно задать более широко: как мы формируем иерархии вычислительных эффектов, как мы их организуем, и почему у нас есть те, которые у нас есть, а не другие, и т. Д.