Обсуждение:Обработка исключений (KQvr';yuny&KQjgQkmtg nvtlZcyunw)

История

Не смог найти, но очень хотелось бы прочитать про историю возникновения концепции исключений. Кто предложил, где появилось впервые. — Эта реплика добавлена участником Alxt (о • в) 10:53, 5 июля 2012 (UTC)

Объединение статей

Поддерживаю объединение статей. По сути, статья Обработка исключений - подмножество статьи Исключения. LoKi 18:19, 15 января 2006 (UTC)

Да, обработка исключений не такой большой или сущесственно выделяющийся раздел чтобы быть отдельным Valodzka 16:06, 26 февраля 2006 (UTC)

Поддерживаю. --yms 09:47, 19 марта 2006 (UTC)

Так как Исключения - слишком широкое понятие ("исключения из правил", "исключения из партии" и т.п.), то она наверняка станет disambiguation page. Поэтому предлагаю объединение произвести под заголовком Обработка исключений, но не наоборот. Bronx 18:06, 31 марта 2006 (UTC)

SEH (Structural Exception Handling)

Ребята, SEH - это не "обработка исключений с применением специальных ключевых слов" вообще, а название конкретной технологии M$! Не надо ее перенаправлять сюда! — Vano 14:58, 24 ноября 2009 (UTC)

Блин! Ёксель-моксель! Не тот язык! Перенаправление-то на статью про SEH я в английской вики делал! :)))) 15:07, 24 ноября 2009 (UTC)

Вообще SEH это structured exception handling и это один из видов обработки исключения. Так что перенаправление в статье SEH нужно сделать на "Структурная обработка исключений"--FIL_обс 17:42, 11 июня 2010 (UTC)

Заумь

"Нулевое значение знаменателя при выполнении операции целочисленного деления."

А слабо написать "При делении числа на ноль."?--Pantzer 16:59, 11 июня 2010 (UTC)

Видите ли, если операция деления не целочисленная, то результатом деления на нуль может быть не только упомянутое исключение, но и (в зависимости от принятой арифметики) плюс- или минус-бесконечность либо значение NAN (Not A Number - "не число"). А вот целочисленное деление на нуль - это всегда ошибка. --dm ^{обсужд.} 18:38, 11 июня 2010 (UTC)

Примеры исключений

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

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

Во-первых, подписывайтесь в обсуждениях!

Во-вторых, программный опрос порта как универсальное решение — это ну очень оригинально! Чисто хохмы ради, попытайтесь прикинуть, как должна работать программа, реагирующая на движение мыши. В смысле — какую частоту опроса она должна обеспечивать, и где при такой частоте опроса портов будет находиться время на остальные операции? В нормальных системах никто ничего не опрашивает — это решается обработкой прерывания от порта, которая с т.з. программы и представляет собой типичный пример обработки асинхронного исключения. Точка выполнения при этом прекрасно сохраняется соответствующими системными средствами, а после обработки прерывания происходит возврат на неё же (в ассемблере 80x86 это, ЕМНИП, была команда IRET). Никакой многопоточности тут близко нет. Тупо опрашивать порт может себе позволить лишь система, у которой огромный избыток процессорного времени и аппаратные буферы на входе порта, гарантирующие от потери данных при задержке вычислений между опросами, да и то не всегда. --dm ^{обсужд.} 14:06, 20 марта 2011 (UTC)

Слышим звон, да не знаем: где он? Я сказал об ожидании события, "тупой опрос" - плод вашего тупого воображения (извините, но частота употребления этого слова в вашем посте просто зашкаливает). Прерывание - это прерывание и исключению не синонимично, так что с ассемблером своим не суйтесь даже: исключения - фича языков исключительно высокого уровня. Приведите какой-нибудь существующий пример уведомления об изменении состояния той же мыши, работающий на исключениях, либо не лезьте в вопросы, в которых совершенно не разбираетесь.85.26.241.222 15:12, 20 марта 2011 (UTC)

Таак. Слово "тупой" в моём комментарии встречается один раз. Жду извинений. Про остальное Вам уже всё объяснили. Да, кстати, реакция на события (в том числе клавиатурные, а также про события в видеоподсистеме, типа совпадения спрайтов на разных уровнях, про мышь не помню) обрабатывались в Basic системы Yamaha MSX с помощью универсальной инструкции ON, как раз и соответствующей обработчику исключений. Да, неструктурному. --dm ^{обсужд.} 18:36, 20 марта 2011 (UTC)

Исключение - это фича не только языков высокого уровня. В ассемблере исключение можно вызывать инструкцией bound. Исключение - это синоним синхронных прерываний. Синхронные прерывания выдаются управляющим блоком процессора после выполнения инструкции. Асинхронные прерывания - это прерывания от других устройств. В нотации Intel асинхронные прерывания названы просто прерываниями, а синхронные - исключениями. Насчёт примера. Я не понял о каком канале идёт речь, но если это про внешнее устройство, тот этот случай уместнее называть прерыванием и тогда действительно лучше подобрать другой пример.--Max 16:08, 20 марта 2011 (UTC)

Просто как-то не вяжется пример с определением: "механизм языков программирования, предназначенный для описания реакции программы на ошибки времени выполнения и другие возможные проблемы (исключения), которые могут возникнуть при выполнении программы и приводят к невозможности (бессмысленности) дальнейшей отработки программой её базового алгоритма." 85.26.241.67 18:28, 20 марта 2011 (UTC)

На самом деле, здесь действительно есть некоторая путаница, но «Исключение — это синоним синхронных прерываний» — это не совсем так. Куда, в таком случае, деть POSIXовский SIGFPE (возникает, в частности, при целочисленном делении на нуль)? По стандарту — это сигнал (фактически — прерывание уровня приложения), которые приложение может либо не обрабатывать, в результате чего его ловит ОС и выгружает приложение из памяти, либо обрабатывать, установив соответствующий асинхронный обработчик. В то же время, при использовании C++, специальным образом написав данный обработчик (раньше в g++ требовалось определённое шаманство, сейчас делается почти элементарно) мы получаем честное C++ — исключение, которое ловится структурными обработчиками. Так исключение это или нет? Событие, нарушающее исполнение программы по текущему алгоритму, то есть исключение — налицо. Дальше работает механизм, который может быть разным. И что? В описанном случае — если оставим только асинхронный механизм, то событие — прерывание, а если добавим к нему ещё кусок, то событие сразу, как по волшебству, станет исключением? Но событие-то одно и то же. Вот и получается, что либо и то, и другое — исключение, либо вообще непонятно, что есть что. И скорее не «исключение — это синхронное прерывание», а «прерывание — это асинхронное исключение» (порядок вложения сущностей другой). Или мы (или я) просто путаемся в терминологии. --dm ^{обсужд.} 21:06, 20 марта 2011 (UTC)

Сигналы это немного другое. Там смешаны исключения типа SIGSEGV и SIGFPE, и не относящиеся к этому вопросу сигналы типа GIGUSR1, SIGKILL. Но если рассмотреть пример с SIGFPE - то это хороший пример синхронного прерывания или исключения. Процессор узнаёт, что во время последней операции делимым был ноль и генерирует исключение (синхронное прерывание). Оно синхронно, потому что его вызывает осознанно сам процессор в определённый момент времени, а не внешнее устройство в непредсказуемый момент. Между прочим в терминологии Intel эта ситуация явно названа исключением, которому присвоен код 0, в ядре linux эта ситуация тоже названа исключением, которое обрабатывается обработчиком исключений divide_error(). Я думаю асинхронными можно назвать все прерывания, генерируемые внешними устройствами, а синхронными (исключениями) - процессором. Я не понял что вы хотели сказать в части про с++/g++ и про превращение событие в исключение. С последним выводом я не согласен, поскольку если придерживаться терминологии Intel понятие "асинхронное исключение" - оксюморон. --Max 22:30, 20 марта 2011 (UTC)

По g++ я имел в виду то, что по умолчанию это исключение (SIGFPE) не является исключением в смысле C++, по крайней мере, для компилятора g++. То есть блоком try{}catch(...) оно не ловится, а ловится отдельно установленным обработчиком - так же, как обрабатываются сигналы, возникающие из-за работы внешних устройств. Но обработчик SIGFPE можно написать так, что он будет создавать исключение C++, которое уже будет ловиться try-catch. То есть сигнал (формально, по стандартному способу обработки - асинхронное событие, хотя для процессора это и не так) превращается в языковое синхронное исключение просто с помощью определённого программного кода. --dm ^{обсужд.} 07:18, 21 марта 2011 (UTC)

В такой ситуации отдельно взятое деление на ноль остаётся синхронным событием, сигнал же- это системный уровень, а не процессорный. В приведённом примере последовательнсть получается такой: деление на ноль (синхронное прерывание или исключение)-> ловля обработчиком исключений ядром системы->сигнал SIGFPE (асинхронное событие)-> catch(...) (синхронное исключение). --Max 07:47, 21 марта 2011 (UTC)

Короче говоря нужно разделять процессорный уровень от системного и языкового.--Max 07:47, 21 марта 2011 (UTC)

Возможно проблема в том, что исключением эмпирически называется что-то связанное с try-catch в C++ или try-except в SEH.--Max 22:30, 20 марта 2011 (UTC)

Кстати в статье Прерывание в начале дана хорошая классификация, так что в основной статье по этой теме путаницы нет. Так всё таки о каком канале данных шла речь?--Max 22:35, 20 марта 2011 (UTC)

Я имел в виду поступление данных на устройство ввода - порт, сетевое устройство или что-то аналогичное. --dm ^{обсужд.} 07:18, 21 марта 2011 (UTC)

Код, слушающий порт, можно заставить генерировать программное исключение, но тогда в основном коде будет много таких обработчиков, которые могут произойти в любой момент времени, и получается, что обработчик занимается событием, которое никак не связано с текущим фреймом.--Max 07:47, 21 марта 2011 (UTC)