Являются ли исключения концепцией ООП?

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

Исключения не являются концепцией ООП.

Но они не совсем не связаны ни с одной маленькой точкой.

Как показали другие ответы: концепция исключений сделана на нескольких не-ООП языках. Ничто в этой концепции не требует чего-то от ООП.

Но любой, если не все языки ООП, которые серьезно относятся к ООП, требуют исключений, потому что другие методы обработки ошибок терпят неудачу в одной конкретной точке: конструкторе.

Одна из точек ООП заключается в том, что объект должен полностью и последовательно инкапсулировать и управлять своим внутренним состоянием. Это также означает, что в чистом ООП вам нужна концепция для создания нового объекта с согласованным состоянием «атомарно» - все, от выделения памяти (если требуется) до инициализации до значимого состояния (т. Е. Простого обнуления памяти недостаточно) быть сделано в одном выражении. Следовательно, требуется конструктор :

Foo myFoo = Foo("foo", "bar", 42);

Но это означает, что конструктор также может потерпеть неудачу из-за некоторой ошибки. Как распространять информацию об ошибках из конструктора без исключений?

• Возвращаемое значение? Сбои, поскольку в некоторых языках newможет возвращаться только, nullно не вся значимая информация. На других языках (например, C ++) myFooнет указателя. Вы не могли проверить это против null. Также вы не можете спросить myFooоб ошибке - она ​​не инициализируется и, следовательно, «не существует» в ООП-мышлении.

• Флаг глобальной ошибки? Так много о инкапсуляции состояния, а затем какой-то глобальной переменной? Перейти к ч ... ;-)

• Смесь? Ни в коем случае не лучше.

• ?

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

Это ООП связано только?

Нет. Исключения и ООП не связаны.

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

Сравнивая C ( не совсем ООП-язык , можно каким-то образом эмулировать исключения в C ) и C ++ (ООП, поддерживает исключения), ничто не мешает стандартному комитету C добавить обработку исключений в C, но все равно не сделает C языком OOP.

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

Объектно-ориентированные языки обычно имеют собственный класс исключений, и в зависимости от контекста слово «исключение» может действительно ссылаться на этот собственный класс вместо общего понятия. Обработка объектно-ориентированных исключений, как и большая часть объектной ориентации, является синтаксическим сахаром и может быть легко эмулирована в решительно не объектно-ориентированных языках. Вот пример C, из викибука C Programming :

#include <stdio.h>
#include <setjmp.h>

jmp_buf test1;

void tryjump()
{
    longjmp(test1, 3);
}

int main (void)
{
    if (setjmp(test1)==0) {
        printf ("setjmp() returned 0.");
        tryjump();
    } else {
        printf ("setjmp returned from a longjmp function call.");
    }
}

Ответ прост: НЕТ.

Хорошим примером для языка без OO с исключениями является ADA.

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

• Oracle PL / SQL

• классический Visual Basic (V6 и ниже, «При ошибке Перейти к» ИМХО является формой обработки исключений)

(Проще говоря, вы найдете некоторые элементы ОО в обоих языках, но механика обработки исключений не использует их, я полагаю, потому что концепция была введена за годы до того, как элементы ОО были добавлены в эти языки).

Основная идея исключений состоит в том, чтобы очистить поток программы, чтобы программист мог легче следовать «нормальному» пути выполнения. Рассмотрим простой случай открытия файла на языке C. Сразу после попытки открыть файл программист должен изучить ответ на вызов fopen () и решить, был ли вызов успешным. Если вызов не удался, программист должен ответить соответствующим образом. Следующий вызов в «нормальном» пути выполнения, возможно вызов fread () или fwrite (), появится после того, как будут обработаны условия ошибки или сбоя. Это может быть на следующем экране.

С языком, который предоставляет исключения, эквивалентный вызов fopen () может сразу же сопровождаться fread () или fwrite (). Нет обработки ошибок, которая скрывает «следующий шаг» «нормального» пути выполнения. Программист может видеть больше обычного пути на одном экране и, таким образом, легче следить за выполнением. Обработка ошибок перенесена в другую часть программы.

Сами исключения не являются концепцией ООП, но они часто реализуются с использованием концепций ООП, которые делают их более удобными и мощными. Например, исключения могут быть определены с иерархией наследования. Используя наш условный пример открытия и чтения или записи файла, каждый из этих вызовов может генерировать различные исключения - FileClosedException, DeviceFullException, NoSuchFileException, InsufficientFilePermissionsException и т. Д. Каждый из них может наследоваться от FileException, который может наследоваться от IOException, что может наследовать от GenericException.

Если программист делает быструю и грязную реализацию для проверки концепции, он может в основном игнорировать обработку исключений и просто реализовать один обработчик для GenericException. Этот обработчик будет обрабатывать GenericException и любое исключение, которое наследуется от GenericException. Если он хочет обрабатывать любое исключение, связанное с файлом, таким же образом, он может написать обработчик для FileException. Это будет вызываться для FileExceptions и любых исключений, которые наследуются от FileException. Если он хочет написать программу, которая будет по-разному реагировать на различные ошибки, он может написать конкретный обработчик для каждого конкретного исключения.

Другие справедливо ответили «Нет» примерами языков. Я подумал, что могу расширить, добавив пример того, как добавлять исключения к языку, не вовлекая ООП.

Я сделаю это в случае с DSKL (декларативным последовательным языком ядра) OZ , языка, хорошо подходящего для подобных вещей. DSKL (или DKL) можно увидеть здесь (результат случайного поиска), заявления и Values часть. Точное определение не имеет значения, за исключением того, что это очень простой язык без изменяемых переменных (они объявляются и привязываются позже), а также не встроен ООП.

ООП нельзя даже добавить в качестве лингвистической абстракции к этому языку ядра. Добавляя уникальные имена к языку ядра (NewName) и используя локальную область видимости, можно добиться инкапсуляции. Или добавляя изменяемое состояние к языку ядра (NewCell) и используя локальную область видимости, можно достичь правильного ООП с инкапсуляцией. Но это не может быть достигнуто только с указанным языком ядра.

Если затем мы добавим исключения к языку ядра, у нас будет язык без поддержки ООП, но есть исключения. Позвольте мне показать, как:

Определив абстрактную машину со стеком и хранилищем, мы можем определить, что должен делать каждый оператор в нашем языке ( семантика оператора). Например, skipв стеке ничего не нужно делать, A = 3в стеке следует связать (/ unify) A с (/ with) 3.

Мы начнем с добавления синтаксиса того, как должны быть определены наши исключения. Мы делаем это, добавляя еще два предложения <statement>в DKL.

<statement>  ::== ... (old stuff)
                 | try <statement> catch <id> then <statement> end
                 | raise <id> end

Вот известный try / catch и способ поднять / выбросить исключения.

Мы определяем их семантику по тому, как они должны работать на абстрактной машине:

Попробуйте
Семантическое утверждение: (try <statement1> catch <id> then <statement2> end)
Do:

1. Вставьте в стек семантическое утверждение (catch <id> then <statement2> end)
2. Вставьте в стек семантическое утверждение (<statement1>)

Обратите внимание, что оператор 1 будет на вершине стека, и попытается выполнить сначала.

Поднять
Семантическое утверждение: (raise <id> end)
Do:

1. Если в стеке больше ничего нет, остановитесь и сообщите о необработанном исключении.
2. Иначе, вытолкните первое семантическое утверждение из стека. Если это не оператор catch, перейдите к шагу 1.
3. Мы получили подвох в форме (catch <id> then <statement> end)
   Push (<statement>)на стек.

Catch
Если мы видим выражение catch во время обычного выполнения, это означает, что все, что было внутри, было выполнено без возведения исключений до этого уровня. Таким образом, мы просто выталкиваем catchстек и ничего не делаем.

КЭД, у нас есть язык с исключениями и нет возможности ООП.

_{Я удалил часть среды из абстрактной машины, чтобы сделать ее проще.}

Нет.

IIRC, исключения появились до первых ОО языков. AFAIK, исключения были впервые поддержаны ранними реализациями LISP. Ранние структурированные языки (например, ALGOL) и ранние ОО-языки (например, SIMULA) не поддерживали исключения.