OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 19 Сентябрь, 2019 03:02

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 100 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Среда, 08 Апрель, 2009 15:12 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 573
Откуда: Россия, Санкт-Петербург
Руслан Богатырев писал(а):
Madzi писал(а):
Позвольте спросить вас с Русланом, а что мешает реализовать такую сигнальную шину без механизма исключений? На уровне операционной системы или надстройки над ней. Да хотя бы на уровне приложения.

Поясняю...

Спасибо. Позиция ясна, но
Руслан Богатырев писал(а):
...
И как сторонник жесткого подхода я против какой-то имитации программистом механизма обработки исключений напрямую средствами ОС...

И в то же время вы предлагаете
Цитата:
Исключения предназначены отнюдь не только для обработки ошибок. Они образуют своего рода сигнальную шину, по которой передаются сигналы о важных событиях, связанных с выполнением программного кода. Как правило, нестандартные/нештатные события, которые требуют соответствующего арбитража.

т.е. имитировать своего рода сигнальную шину.

А какая беда будет в том, что в операционной системе будет специальный стек сообщений, который программы смогут использовать по своему усмотрению?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 15:18 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 22:34
Сообщения: 431
Откуда: Москва
Madzi писал(а):
Таким образом: имеем сомнительную пользу при явных недостатках.


Сомнительную пользу исключений? Боюсь, подобным анализом Вы скорее убеждаете себя, но не оппонентов. :wink: Не делайте категоричных выводов, тем более, в тех вопросах, в которых (судя по Вашей аргументации) имеете весьма скромный опыт.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 15:35 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
Руслан Богатырев писал(а):
...асинхронной работы добиваются за счет жесткой синхронизации с обработчиком (исключения). За счет по сути программного прерывания.
Тут вопрос терминологии. Программным прерыванием (в отличие от аппаратного прерывания) обычно называется явный вызов обработчика прерывания из программы (обычно команды процессора TRAP, EMT и т.п.). Что никакого отношения не имеет к механизму исключений в языках высокого уровня...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 16:06 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3064
Откуда: Астрахань
ИМХО на тему исключений.
Собственно, вопрос только в одном: обязательно ли обрабатывать возникшую ситуацию исключительно в месте возникновения или разрешено отправить сообщение более "компетентным товарищам".
Если смотреть на С++, то коды ошибок не катят в перегрузке операций и в конструкторах. Просто нет лишнего параметра, а для конструктора - и возвращаемого результата.
Говорите, что нафига нам конструкторы и перегрузка операций. Ни нафига - можно из убрать вполне, что и сделано в Оберонах.
Почему бывает, что на месте нельзя разобраться и обработать ошибку.
Допустим, в процедуру данные поступают из базы данных, а в базу данных они еще откуда-нибудь попадают (например, ручками вбиваются оператором или вообще с датчиков читаются).
Обрабатывающую процедуру кто-то вызывал - через десятые руки данные до нее дошли. И тут выясняется, что данные - плохие. Как раз в непрерывано работающих системах требуется, чтобы не было аварий, поэтому процедура должна сообщить отправляющему, что он прислал неформат. Пусть исправит и пришлет то, что нужно.
Передавать через 10-е руки коды ошибок - это кошмар, который пришлось переживать промышленным программерам в свое время. В этом смысле генерация исключения - это посылка сообщения "на предъявителя" - у кого есть соответствующий мандат - обработчик исключения.

Исключения исключительно :) хорошо подходят для одной из моделей параллельного программирования (описана у Бен-Ари, забыл как называется. Линда, кажется). Другое дело, что в обычных последовательных языках исключения - несколько инородный с идеологической точки зрения механизм.
Но утверждать, что они вредны - это перебор.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 16:14 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 573
Откуда: Россия, Санкт-Петербург
Валерий Лаптев писал(а):
ИМХО на тему исключений.
...
Почему бывает, что на месте нельзя разобраться и обработать ошибку.
Допустим, в процедуру данные поступают из базы данных, а в базу данных они еще откуда-нибудь попадают (например, ручками вбиваются оператором или вообще с датчиков читаются).
Обрабатывающую процедуру кто-то вызывал - через десятые руки данные до нее дошли. И тут выясняется, что данные - плохие. Как раз в непрерывано работающих системах требуется, чтобы не было аварий, поэтому процедура должна сообщить отправляющему, что он прислал неформат. Пусть исправит и пришлет то, что нужно.
Передавать через 10-е руки коды ошибок - это кошмар, который пришлось переживать промышленным программерам в свое время. В этом смысле генерация исключения - это посылка сообщения "на предъявителя" - у кого есть соответствующий мандат - обработчик исключения.

То, что вы описываете не совсем понятно. С одной стороны "непрерывно работающая система", с другой стороны "на десятые сутки пошлёт неформат отправителю".
Реально либо используют робасные (не подверженные влиянию ошибок) процедуры обработки данных, с записью в лог об обнаруженных несоответствиях (можно сделать исключением, но правильно сделать на основе событий), либо проверяют/корректируют данные в момент сбора.

Валерий Лаптев писал(а):
Исключения исключительно :) хорошо подходят для одной из моделей параллельного программирования (описана у Бен-Ари, забыл как называется. Линда, кажется). Другое дело, что в обычных последовательных языках исключения - несколько инородный с идеологической точки зрения механизм.
Но утверждать, что они вредны - это перебор.

Рискну предположить, что описывается событийная модель, которая может быть реализована с помощью исключений, но правильно её реализовать с помощью специальной очереди событий. "Каждой гайке - свой болт" (с)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 16:56 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3064
Откуда: Астрахань
Еще мне кажется, что применение или неприменение исключений может зависеть от масштаба разработки. В небольших проектах со слаженной компетентной командой можно договориться о способе обработки нештатных ситуаций.
Для больших масштабов, в которых команда состоит из нескольких десятков, а то и сотен человек, лучше иметь некий стандартнно включенный в инструментарий механизм обработки нештатных ситуаций.
В этом плане механизм исключений полезен, поскольку требует от программиста задуматься, что, собственно делать, если все плохо.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 17:09 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 573
Откуда: Россия, Санкт-Петербург
:) "... мир чёрно-бел, мир чёрно-бел ..." на самом деле он серый. Это я к тому, что использовать или не использовать механизм обработки исключительных ситуаций - вопрос сугубо личный. Ситуация не изменится только потому что исключения мне не нравятся (или наоборот). Просто каждый должен чётко понимать ЗАЧЕМ ему это нужно, и если вносится ДОПОЛНИТЕЛЬНАЯ СЛОЖНОСТЬ, то чётко давать себе отчёт что это ПОТЕНЦИАЛЬНЫЙ ИСТОЧНИК ОПАСНОСТИ.
Если входные данные проверяются перед обработкой на допустимость, а также существует проверка выходных данных, то исключительным ситуациям взяться просто неоткуда.
Механизм обработки исключений содержит в себе БОЛЬШОЙ СОБЛАЗН, отложить работу на потом (проверить данные не на месте их обработки, а где-то ещё, что не добавляет понимания при чтении программы), или, что ещё хуже, ПЕРЕЛОЖИТЬ РАБОТУ НА ДРУГОГО программиста (хуже потому, что возникают опасности ошибок сломанного телефона - один имел ввиду одно, другой понял совершенно другое).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 17:23 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3064
Откуда: Астрахань
Суть в том, что нештатные ситуации нужно как-то обрабатывать. Делать это с помощью исключений или с помощью тотальной проверки входных данных - это, мне кажется, вопрос конкретного подхода.
Сишники предложили тот вариант, который им показался удобнее.
Мейерс в Альфарде включил утверждения непосредственно в язык - ему так показалось удобнее. Оберон ничего не включил, но для обработки нештатных ситуаций все равно требуется согласовать некий общий принцип обработки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 18:07 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Madzi писал(а):
Что поделать. Без теории никому нельзя. Иначе будем постоянно ходить по граблям.


Теория без практики мертва.

Madzi писал(а):
Мне бы очень понравилось, потому что винду бы не смогли продать до тех пор пока не выловили и уничтожили большинство присутствующих в ней ошибок.


Ее бы просто не выпустили. Сидели бы вы сейчас на чем-нибудь типа ZX-Spectrum и программировали на бэйсике - как раз к настоящему времени там бы все ошибки вычистили :)

Madzi писал(а):
Не понял вашу вторую часть, несмотря на смайлик. У вас "программой" что-то ещё называется?


"Программа" в терминах ББ и в "классическом" виде (exe) - разные штуки. Нет?

Madzi писал(а):
Хорошая программа не будет обрабатывать коды ошибок, она просто не допустит ошибочной ситуации.


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

Madzi писал(а):
Не знаю, что вы имели ввиду отправляя меня в википедию


Извините, что отправил на википедию, просто более адекватной ссылки под рукой нет. Впрочем на википедии все основное рассказано (хотя по моему мнению не хватает нужных акцентов).

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


Блин. Ну что вы носитесь со своей структурностью? Это самоцель такая или что? Это всего лишь средство для улучшения качества программ. И борьба с goto ведется не из принципа, что оно не структурно, а потому что качество программ страдает. А структурность, как подход, позволяет избавиться от goto предлагая другое решение тех же проблем, которое решает goto. Как только структурность (во всяком случае в вашем понимании, потому что мы имеем некоторые расхождения в ее понимании) идет против качества или нифига не решает - нафиг такую структурность. Берем другое средство. Помимо структурности есть другие способы повысить качество. Механизм исключений - одно из таких средств. По моему мнению совершенно ортогональное структурности (при правильном использовании).
Лет 5 назад я сам доказывал на форумах, что "исключения - это goto, только еще хуже, потому что фиг знает куда оно улетит и кто его поймает". Пока не увидел как можно правильно писать с исключениями :) Насколько яснее и прозрачнее становится код. Разница примерно такая же как между макаронным кодом с кучей goto и кодом в лучших традициях структурного программирования :) Как это показать на примере - я не знаю, надо просто поработать с правильным кодом.

Madzi писал(а):
И ответная просьба - прочтите наконец Дейкстру и воздержитесь от написания сюда постов, если они прямо противоречат тому, о чём вы прочтёте.


Я прочту Дейкстру, если мне скажут, что я там найду что-то принципиально новое - помимо того, что в популяризованной форме изложено у Гриса. Еще раз повторюсь - любая теория хороша, если она помогает в практике. Если она не помогает или даже мешает - практика использует другую теорию или адаптирует существующую.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 18:12 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 573
Откуда: Россия, Санкт-Петербург
Валерий Лаптев писал(а):
Суть в том, что нештатные ситуации нужно как-то обрабатывать. Делать это с помощью исключений или с помощью тотальной проверки входных данных - это, мне кажется, вопрос конкретного подхода.
Сишники предложили тот вариант, который им показался удобнее.
Мейерс в Альфарде включил утверждения непосредственно в язык - ему так показалось удобнее. Оберон ничего не включил, но для обработки нештатных ситуаций все равно требуется согласовать некий общий принцип обработки.

Нештатные (чрезвычайные/исключительные) ситуации не должны возникать в грамотно спроектированной программе. Т.е. программист (создатель) должен предусмотреть все возможные ситуации. Существует даже направление моделирования программ в виде конечных автоматов. Так что решение вопроса лежит в методологической плоскости, а не в практической.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 18:30 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 573
Откуда: Россия, Санкт-Петербург
Vlad писал(а):
Ее бы просто не выпустили. Сидели бы вы сейчас на чем-нибудь типа ZX-Spectrum и программировали на бэйсике - как раз к настоящему времени там бы все ошибки вычистили :)

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

Vlad писал(а):
Madzi писал(а):
Не понял вашу вторую часть, несмотря на смайлик. У вас "программой" что-то ещё называется?

"Программа" в терминах ББ и в "классическом" виде (exe) - разные штуки. Нет?

Если честно, с ББ (BlackBox) у меня не очень сложилось, всё как-то больше с ББ (BlueBottle). :) Ну ещё классический Оберон (который Trianus). Хотя решил по окончании семестра найти время на ББ (BlackBox).

Vlad писал(а):
Madzi писал(а):
Хорошая программа не будет обрабатывать коды ошибок, она просто не допустит ошибочной ситуации.


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

Нетворку вы выдерните, но обрабатывать отсутствие сети будет драйвер, а ОС узнает по соответствующей переменной в драйвере, что сеть отсутствует. Всё это будет в штатном режиме, а не по исключениям. Заранее предусмотрено разработчиком.

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


Блин. Ну что вы носитесь со своей структурностью? Это самоцель такая или что? Это всего лишь средство для улучшения качества программ. И борьба с goto ведется не из принципа, что оно не структурно, а потому что качество программ страдает. А структурность, как подход, позволяет избавиться от goto предлагая другое решение тех же проблем, которое решает goto. Как только структурность (во всяком случае в вашем понимании, потому что мы имеем некоторые расхождения в ее понимании) идет против качества или нифига не решает - нафиг такую структурность. Берем другое средство. Помимо структурности есть другие способы повысить качество. Механизм исключений - одно из таких средств. По моему мнению совершенно ортогональное структурности (при правильном использовании).
Лет 5 назад я сам доказывал на форумах, что "исключения - это goto, только еще хуже, потому что фиг знает куда оно улетит и кто его поймает". Пока не увидел как можно правильно писать с исключениями :) Насколько яснее и прозрачнее становится код. Разница примерно такая же как между макаронным кодом с кучей goto и кодом в лучших традициях структурного программирования :) Как это показать на примере - я не знаю, надо просто поработать с правильным кодом.

Вас все давно просят - приведите пример "правильного" кода. Мне он пока не встречался. А там где исключения "проясняли" программную суть, можно было обойтись и без них, не менее ясно.
Я не поборник структурного подхода. Я просто хочу, чтобы программы содержали как можно меньше ошибок. К сожалению, я не в силах повысить грамотность и проф.навыки огромной армии непрофессиональных программистов, себя такими возомнивших (к настоящим профессионалам это не относится). Но структурный подход позволит создать средства жёсткого контроля и автоматической верификации. Кроме того, структурный подход прививает при обучении грамотный стиль. Когда мы учим в школе русский язык, то мы стараемся придерживаться определённых правил, а не пишем так как слышим (хотя некоторые так и делают). "Ведь ВИЛАСИПЕД мотороллером не станет, если я напишу его так" (с) детский рассказ. А в информатике, к сожалению, сейчас, в основном, попадаются ВИЛАСИПЕДЫ. Потому что правильно писать не научили. А если человек грамотный, то он сам разберётся что хорошо, а что плохо и что, где и когда использовать (возвращаясь к исключениям).

Vlad писал(а):
Madzi писал(а):
И ответная просьба - прочтите наконец Дейкстру и воздержитесь от написания сюда постов, если они прямо противоречат тому, о чём вы прочтёте.


Я прочту Дейкстру, если мне скажут, что я там найду что-то принципиально новое - помимо того, что в популяризованной форме изложено у Гриса. Еще раз повторюсь - любая теория хороша, если она помогает в практике. Если она не помогает или даже мешает - практика использует другую теорию или адаптирует существующую.

:) Какая-то детская позиция. Пока не прочтёте точно не узнаете. Вообще нужно стараться поднимать свой уровень, в том числе полезных книг, даже если не найдёте в них чего-то ПРИНЦИПИАЛЬНО НОВОГО. Ведь ничего ПРИНЦИПИАЛЬНО НОВОГО с 80х годов 20 века в программировании не появилось.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 19:01 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Madzi писал(а):
Примеры показывают, что во втором случае программист заранее предусмотрел "исключительный" вариант.


Ну и толку, что он предусмотрел? Адекватно обработать ошибку он все равно не смог, он ее замазал. Хорошо, если еще в лог чего-нибудь написал. Когда будут разбираться (через месяц), почему на счет бабульке поступила пенсия астрономического размера, возможно даже эту запись в логе найдут и даже смогут докопаться почему так получилось :) А может так и не докопаются, потому что в логе только эта запись, а откуда вызвалась эта функция и как получились такие аргументы - ХЗ. Поставят очередную заплатку - если пенсия больше чем ВВП, то не выпендриваться, а кидать исключение :)

Madzi писал(а):
Практика показывает, что первый вариант возникает когда автору некогда/лень разбираться с алгоритмом, который иногда сбоит...


Практика показывает, что программист обычно уверен, что его алгоритм не сбоит. Что вы и доказали своим собственным примером ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 19:26 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Madzi писал(а):
Цитата:
Достоинства использования исключений особенно заметно проявляется при разработке библиотек процедур и программных компонентов, ориентированных на массовое использование. В таких случаях разработчик часто не знает, как именно должна обрабатываться исключительная ситуация (при написании универсальной процедуры чтения из файла невозможно заранее предусмотреть реакцию на ошибку, так как эта реакция зависит от использующей процедуру программы), но ему это и не нужно — достаточно сгенерировать исключение, обработчик которого предоставляется реализовать пользователю компонента или процедуры. Единственная альтернатива исключениям в таких случаях — возврат кодов ошибок, которые вынужденно передаются по цепочке между несколькими уровнями программы, пока не доберутся до места обработки, загромождая код и снижая его понятность.

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

Итак, достоинство:
1. В том, что вместо того, чтобы обработать ошибку на месте программист (ссылаясь на незнание мотивов другого программиста) перекладывает обработку на плечи "потомка" (отмазка).


Это не отмазка, это насущная необходимость. Библиотечная функция в принципе не может знать что делать с нечитающимся файлом. Так что обработка ошибки в любом случае отдается кому-то еще. В случае использования наличия исключений это делается с помощью механизма специально для этого предназначенного. Без механизма исключений - по старинке через коды возврата, которые путаются с аргументами и результатами других функций и превращают даже простую линейную "основную" логику программы в нагромождение IF/ELSE по всей цепочке вызовов.

Madzi писал(а):
(При этом ссылаются на процедуру чтения из файла. Всё что нужно знать при чтении из файла, так это прочитаны данные - всё хорошо, или не прочитаны - есть ошибка. Можно, конечно, используя код ошибки передавать причину неудачи: отсутствует файл, занят другим ресурсом и т.п., но как правило для родительской программы это не важно).


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

Madzi писал(а):
2. Безусловно, читаемость кода возрастает, поскольку сразу виден опасный участок и его обработка,


Нет. Читаемость кода возрастает не поэтому. А потому что логика обработки ошибки отделена от основной полезной логики. Перепишите вот такой простой код:
Код:
f(g());


по всем правилам структурного (в вашем понимании) программирования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 19:33 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Madzi писал(а):
Нештатные (чрезвычайные/исключительные) ситуации не должны возникать в грамотно спроектированной программе.


Во видите, вы сами чувствуете разницу между "не должны" и "не возникают" :) Они возникают. И никакой методологией вы от этого не избавитесь. До тех пор, пока программы будут писать люди :) Поэтому подумать над тем, что с такими ситуациями делать - крайне полезно :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 20:08 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Madzi писал(а):
Нетворку вы выдерните, но обрабатывать отсутствие сети будет драйвер, а ОС узнает по соответствующей переменной в драйвере, что сеть отсутствует. Всё это будет в штатном режиме, а не по исключениям. Заранее предусмотрено разработчиком.


Такое чувство, что вы запутались в терминологии. Что вы здесь называете "штатным режимом" и что "исключением"? Коды возврата против try/catch?

Madzi писал(а):
Вас все давно просят - приведите пример "правильного" кода. Мне он пока не встречался.



См. мой предыдущий пост с "f(g());".

Madzi писал(а):
Но структурный подход позволит создать средства жёсткого контроля и автоматической верификации.


Пока наиболее близок к автоматической верификации функциональный подход ;) Впрочем как вам может помешать верификации break/return - я не совсем понимаю. По сравнению с такой штукой как "побочный эффект" это настолько незначительная мелочь...

Madzi писал(а):
:) Какая-то детская позиция. Пока не прочтёте точно не узнаете.


Ну блин. Вы мне еще собрание сочинений Ленина предложите прочесть :) Я считаю, что достаточно хорошо представляю о чем пишет Дейкстра. Считаю не просто так, а потому что прочел Гриса.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 20:44 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 573
Откуда: Россия, Санкт-Петербург
Vlad писал(а):
См. мой предыдущий пост с "f(g());".


Код:
res := g();
f(res);


И это за вас сделает потом компилятор.

Vlad писал(а):
Ну блин. Вы мне еще собрание сочинений Ленина предложите прочесть :) Я считаю, что достаточно хорошо представляю о чем пишет Дейкстра. Считаю не просто так, а потому что прочел Гриса.

Ленина тоже полезно, хотя лучше Сталина. По сути почти о том же, но более сжато и информативно. Вот Мао читать не советую, хотя у него я тоже встретил интересные моменты.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 21:01 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Madzi писал(а):
Код:
res := g();
f(res);


И это за вас сделает потом компилятор.


Эта... А где обработка ошибок? И какой компилятор что за меня сделает?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2009 23:04 

Зарегистрирован: Вторник, 18 Сентябрь, 2007 08:48
Сообщения: 108
На Королевстве Delphi есть классная статья "Обработка ошибок". И довольна таки большая.
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=1392

А вот и отправная точка:
Цитата:
И только не надо говорить, что в правильной и отлаженной программе такого не возникнет. Возникнет, не сомневайтесь. К сожалению, создание программ требует написания кода :) И не важно, как вдумчиво вы планировали архитектуру, внимательно писали код и тщательно тестировали функциональность — вы просто физически не в силах предусмотреть ЛЮБУЮ возможную ситуацию, в которой будет выполняться ваша программа. Кроме того, хотя программа-то всегда выполняет то, что в неё заложили, но вот люди (как программисты, так и пользователи) — они, знаете ли, совершают ошибки. И если ошибка будет не в вашем коде, то уж в чужом точно (вы ведь не пишете программу от и до, включая операционную систему, драйверы и BIOS, верно? Ах да, я забыл — вы же пишете на Delphi :) Это значит, что вы не контролируете как минимум код самой Delphi). Поэтому свою программу просто необходимо подготавливать к возникновению в ней ошибок. И будет лучше, если мы с вами сможем сделать что-то с этой ситуацией заранее.


Читать надо долго и вдумчиво :wink:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2009 13:16 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3064
Откуда: Астрахань
Madzi писал(а):
Валерий Лаптев писал(а):
Суть в том, что нештатные ситуации нужно как-то обрабатывать.

Нештатные (чрезвычайные/исключительные) ситуации не должны возникать в грамотно спроектированной программе. Т.е. программист (создатель) должен предусмотреть все возможные ситуации. Существует даже направление моделирования программ в виде конечных автоматов. Так что решение вопроса лежит в методологической плоскости, а не в практической.

Это - идеализм.
Во-первых, данные могут быть какие угодно: оператор вбивал и вбил неправильно.
Во-вторых, в маленькой программе из нескольких десятков тысяч операторов (примерно до 100 000) такое возможно. Именно потому, что такую прогу способны написать 2-3-4 человека в приемлемые сроки. Но в большой, содержащей сотни тысяч и миллионы строк - такое в принципе невозможно. Именно потому, что слишком большой проект, слишком команда большая. Да еще текучесть кадров. Каждый новый программер будет по-своему обрабатывать ошибки - наступит полный хаос.
Нужен формализованный аппарат.
Или явно зафиксированный документ: дисциплина обработки нештатных ситуаций. На самотек такое пускать нельзя.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2009 14:48 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 573
Откуда: Россия, Санкт-Петербург
Валерий Лаптев писал(а):
Во-первых, данные могут быть какие угодно: оператор вбивал и вбил неправильно.

Данные всегда могут быть какие угодно, не обязательно в компьютере. Есть такой статистический раздел "Разведочный анализ данных", как раз направлен на поиск и выявление "выбросов". Кстати говоря, есть даже теория восстановления пропусков (около 15 методов). Если задача того требует, то нужно грамотно строить теоретическую базу.

Валерий Лаптев писал(а):
Во-вторых, в маленькой программе из нескольких десятков тысяч операторов (примерно до 100 000) такое возможно. Именно потому, что такую прогу способны написать 2-3-4 человека в приемлемые сроки. Но в большой, содержащей сотни тысяч и миллионы строк - такое в принципе невозможно. Именно потому, что слишком большой проект, слишком команда большая. Да еще текучесть кадров. Каждый новый программер будет по-своему обрабатывать ошибки - наступит полный хаос.

:) Вы как будто бы не на тематическом форуме. Оберон потому и появился, чтобы дать возможность программисту разбить большой, содержащий миллиарды строк код на небольшие, обозримые модули, независимо компилируемые и функционирующие сами по себе, и стройно объединяющиеся в общий проект. Это сделано СПЕЦИАЛЬНО чтобы ОБЛЕГЧИТЬ ЖИЗНЬ программисту. Только программисты пока кричат что "Си/++/# - круто, а Оберон - отстой" (Vlad, это я НЕ ПРО ВАС).

Валерий Лаптев писал(а):
Нужен формализованный аппарат.
Или явно зафиксированный документ: дисциплина обработки нештатных ситуаций. На самотек такое пускать нельзя.

Дык. Уже работаю над этим.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 100 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB