Как не следует делать это - Ada пример
Как не следует делать это - Ada пример
Приведу пример программы, взятый из одного учебника12.1) по языку Ada.
sqrt (x: REAL) return REAL is
begin
if x < 0.0 then
raise Negative
else
normal_square_root_computation
end
exception
when Negative =>
put ("Negative argument")
return
when others => ...
end -- sqrt
Этот пример, вероятно, предназначался для синтаксической иллюстрации механизма Ada, и был написан быстро (он, например, отказывается возвращать значение в случае возникновения исключения). Поэтому было бы непорядочно критиковать его, как если бы это был настоящий пример хорошего программирования. Вместе с тем, он ясно показывает нежелательный способ обработки исключений. Поскольку Ada ориентирована на военные и космические приложения, то остается надеяться, что ни одна из реальных программ не следует буквально этой модели.
Целью программы является получение вещественного квадратного корня из вещественного числа. Но что если число отрицательно? В языке Ada нет утверждений, так что в программе проводится проверка, возбуждающая исключение для отрицательных чисел.
Инструкция raise Exc прерывает выполнение текущей программы и включает исключение с кодом Exc. Это исключение может быть захвачено и обработано при наличии предложений exception, имеющих вид:
exception
when code_a1, code_a2, ...=> Instructions_a;
when code_b1, ... => Instructions_b;
...
Если код исключения совпадает с одним из кодов, указанных в части when, то выполняются соответствующие инструкции. Если, как в примере, есть предложение when others, то его инструкции выполняются, когда код исключения не совпадает ни с одним из кодов предыдущих частей when. Если нет универсального обработчика when others, и код исключения не совпадает ни с одним кодом, то поиск обработчика будет вестись у вызывающей программы, если вызывающей программы нет, то достигнута программа main и программа завершается отказом.
В примере нет необходимости переходить к вызывающей программе, поскольку выброшенное исключение с кодом Negative захватывается обработчиком с таким же кодом.
Но что делают соответствующие инструкции? Посмотрите еще раз:
put ("Negative argument")
return
Напечатается сообщение - довольно глубокомысленное, а затем управление перейдет к вызывающей программе, которая, не будучи уведомлена о событии, продолжит свое выполнение, как если бы ничего не случилось. Вспоминая снова о типичных приложениях Ada, можно лишь надеяться, что этой схеме не следует артиллерийское приложение, в результате которой снаряды могут упасть на головы совсем не тех солдат, для которых вряд ли может служить утешением посланное сообщение об ошибке.
Эта техника, вероятно, хуже, чем C-Unix сигнальный механизм, позволяющий, по крайней мере, возобновить вычисление в точке, где оно остановилось. Обработчик исключения when, заканчивающийся инструкцией return, даже не продолжает текущую программу; он возвращает управление вызывающей программе, будто бы все прекрасно, в то время как все далеко не прекрасно.
Этот контрпример дает хороший урок Ada-программистам: почти ни при каких обстоятельствах обработчик when не должен заканчиваться return. Слово "почти" употреблено для полноты картины, поскольку есть особый допустимый случай ложной тревоги (false alarm), достаточно редкий, который мы обсудим чуть позже. Опасно и неприемлемо не уведомлять вызывающую программу о возникшей ошибке. Если невозможно исправить ситуацию и выполнить контракт, то программа должна выработать отказ. Язык Ada позволяет сделать это: предложение exception может заканчиваться инструкцией raise без параметров, повторно выбрасывая исходное исключение, передавая его вызывающей программе. Это и есть подходящий способ завершения выполнения, когда невозможно выполнить свой контракт.
Правило исключений языка Ada
Выполнение любого обработчика исключений должно заканчиваться либо выполнением инструкции raise, либо повторением объемлющего программного блока.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКЧитайте также
Чего следует остерегаться
Чего следует остерегаться Главное, чего следует остерегаться при поиске вакансий, – это мошенничества. Интернет со своей конфиденциальностью – настоящий рай для мошенников всех мастей. Нет, я, конечно, не советую вам превращаться в параноика и начать подозревать всех и
* Продолжение следует??
* Продолжение следует?? - Даже не знаю, что тебе ответить. Предыдущий текст я писал примерно год назад, затем запал спал, появились новые задачи, то да сё, сам понимаешь.* Не отбрешешься!- Да, помнится, были задумки, но чтобы продолжить надо опять сосредоточится в нужное
Когда следует записывать макрос
Когда следует записывать макрос Макросы экономят время и снимают раздражение. Это действительно так. Компьютер воспроизведет последовательность команд куда быстрее, чем это сделаете вы, щелкая на соответствующих кнопках команд и выбирая пункты соответствующих меню.
0. Не мелочитесь, или Что не следует стандартизировать
0. Не мелочитесь, или Что не следует стандартизировать РезюмеСкажем кратко: не мелочитесь.ОбсуждениеВопросы персонального вкуса, которые не влияют на корректность и читаемость кода, не относятся к стандарту кодирования. Любой профессиональный программист сможет легко
72. Для уведомления об ошибках следует использовать исключения
72. Для уведомления об ошибках следует использовать исключения РезюмеДля уведомления об ошибках лучше использовать механизм исключений, а не коды ошибок. Применять коды состояния (например, коды ошибок, переменную errno) следует только тогда, когда нельзя использовать
74. Уведомляйте об ошибках, обрабатывайте и преобразовывайте их там, где следует
74. Уведомляйте об ошибках, обрабатывайте и преобразовывайте их там, где следует РезюмеСообщайте об ошибках в тот момент, когда они обнаружены и идентифицированы как ошибки. Обрабатывайте или преобразовывайте их на самом нижнем уровне, на котором это можно сделать
7.3. Проблемы и методы, которых следует избегать
7.3. Проблемы и методы, которых следует избегать Несмотря на то, что BSD-сокеты через TCP/IP стали доминирующим IPC-методом в Unix, до сих пор продолжаются оживленные споры по поводу правильного способа разделения программ средствами мультипрограммирования. Некоторые устаревшие
19.4. Почему следует использовать стандартную лицензию
19.4. Почему следует использовать стандартную лицензию Широко известные лицензии, которые согласуются с Определением открытого исходного кода (Open Source Definition), имеют твердо установившиеся "толковательные" традиции. Разработчики (и пользователи, в той мере, как это их
Какие главы следует прочитать
Какие главы следует прочитать Это небольшая книжка, поэтому не ленитесь. Прочтите ее целиком, ведь никогда не знаешь, над чем предстоит работать в будущем.Но все же есть грехи, которым подвержены лишь некоторые языки и некоторые среды, поэтому важно, чтобы в первую очередь
ОКНО ДИАЛОГА: Знать, что делать, а не как делать
ОКНО ДИАЛОГА: Знать, что делать, а не как делать 19 сентября 2005 года исполнилось пятнадцать лет с момента появления Интернета в России. 19 сентября 1990 года был зарегистрирован домен su. Отечественный сегмент всемирной сети был создан во многом благодаря сотрудникам
ПИСЬМОНОСЕЦ: Посылаем читателей куда не следует
ПИСЬМОНОСЕЦ: Посылаем читателей куда не следует Автор: Илья Щуров VoyagerВыношу на ваш суд рацпредложение, касающееся оформления журнала. Поскольку практически каждый номер содержит в одной или нескольких статьях сноски, состоящие из километровых ссылок на веб-ресурсы,
Что следует повторно использовать?
Что следует повторно использовать? Убедив себя в том, что Повторное использование - Это Хорошо, осталось выяснить, как же этого добиться?Первый возникающий вопрос - на каком уровне следует осуществлять повторное использование: персонала, спецификаций, проектов, их
Как не следует делать это - C-Unix пример
Как не следует делать это - C-Unix пример Первым контрпримером механизма (наиболее полно представленным в Unix, но доступным и на других платформах, реализующих C) является процедура signal, вызываемая в следующей форме:signal (signal_code, your_routine)с эффектом вызова обработчика исключения -
Какие подробности следует опубликовать
Какие подробности следует опубликовать После того как вы обнаружили и выявили уязвимость, потребуется определить, какие именно сведения следует включить в сообщение. В основном ваше решение будет зависеть от того, кому вы собираетесь направить сообщение. Но обычно в
Глава 25. Когда не следует использовать ХР
Глава 25. Когда не следует использовать ХР Точные пределы использования ХР еще не до конца исследованы. Однако есть известный набор факторов, который делает применение ХР невозможным, – слишком большие команды, недоверчивые заказчики, технология, которая не позволяет