Delphi типы исключений.

← →
defunct © (2008-01-28 01:31) [120]

> Игорь Шевченко © (27.01.08 19:20) [33]
> Ситуацию нельзя исправить никогда.

Иногда можно - попытаться повторить операцию.
И иногда это помогает - пример intermittent bad block на диске.

← →
Игорь Шевченко © (2008-01-28 01:37) [121]

Семеныч (28.01.08 01:23) [119]

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

Хорошо вам. На одну данную одну форму используете. А данная возьми да приди еще из пары источников, откуда ее тоже надо проверять, да не просто проверять, а всячески преобразовывать, то есть конвертировать.

И придется кроме формы еще в паре месте менять, да не забыть сделать ошибок :)

← →
Игорь Шевченко © (2008-01-28 01:45) [122]

defunct © (28.01.08 01:31) [120]

Конечно можно повторить. В свое время (еще до тырнета) ходила статья "Записки парасистемного программиста". Хорошая, кстати, статья. О программном обеспечении IBM S/360, почему это у них такое обеспечение - чуть ошибка в оборудовании - оно, обеспечение, завершается с ошибкой.
Вместо того, чтобы попытаться повторить операцию, произвести диагностику аппаратуры и тому подобные действия.

Так там была хорошая фраза - что программа должна обладать способностью при любом сбое не произвести во внешней среде необратимых изменений. Например не дергать винтом почем зря, в надежде на то, что bad block исправится.

← →
Семеныч (2008-01-28 01:59) [123]

> Игорь Шевченко © (28.01.08 01:37) [121]

Вот неплохой вариант (в общих чертах, детали опускаю).

Есть таблица БД. Пишем невизуальный класс, который эту таблицу отображает на свои свойства. В нем же - метод валидации данных (поскольку он сам про себя все знает, пусть сам себя и проверяет). В нем же - проверки допустимости операций (методы типа CanBeModified). И все такие классы - потомки одного (а в нем - базовый функционал).

Далее - пишем универсальный диалог редактирования таких классов. В его конструкторе есть параметр - экземпляр такого класса. Диалог создает свои контролы не из DFM, а динамически, используя RTTI полученного объекта. Когда диалогу нужно что-то проверить - вызывается нужный метод редактируемого объекта.

Изменилась задача - вносим изменения в тот самый невизуальный класс. И все, код GUI не меняется. И разделение данных с GUI имеется. И кумира нет.
:о)

← →
ketmar © (2008-01-28 02:16) [124]

>[119] Семеныч (28.01.08 01:23)
а ты меня опять читал невнимательно. ты описал случай классической «задачи с одной формой». для которой, как я говорил, подобное разделение может быть и избыточным.

>[123] Семеныч (28.01.08 01:59)
оно всё очень красиво выглядит, пока до практики не доходит. пока юзер не скажет: «хочу вот тут кнопочку, тут перделочку, а на фоне — бабу голую». после чего наш «универсальный гуй» начинает обрастать дикими костылями, за которыми универсальности уже и не видно.

← →
Семеныч (2008-01-28 02:24) [125]

> ketmar © (28.01.08 02:16) [124]

> с одной формой

Какая там одна форма... их десятки, а может и за сотню уже перевалило... и ничего, живет...

> которыми универсальности уже и не видно.

А это как гуй спроектируешь. Там ведь тоже наследования никто не отменял, неуниверсальную бабу можно и в наследнике рисовать.

← →
Семеныч (2008-01-28 02:31) [126]

Ладно, пошел я спать. Всем спасибо, интересно было.

← →
ketmar © (2008-01-28 02:31) [127]

>[125] Семеныч (28.01.08 02:24)
>их десятки, а может и за сотню уже перевалило
и что, нигде логика от отображения не отделена? хорошо, ай, как хорошо-то…

>еуниверсальную бабу можно и в наследнике рисовать.
тогда зачем городить какой-то автопостроитель форм в рантайме, если всё равно напильником работать? я бы сделал специализированный редактор a-la сама Delphi, где есть пункт «создать прототип на основе модели» и дальше ты его руками доводишь, если надо. указывая связи и прочее. заодно эту ерундень можно продать особо умным юзерам, которые достаточно подкованы для создания своих вариантов UI.

← →
Семеныч (2008-01-28 02:41) [128]

> ketmar © (28.01.08 02:31) [127]

Блин... хрен тут уйдешь...
:o)

> нигде логика от отображения не отделена?

Отделена, конечно, не полные же идиоты проектировали. Не нужно же так уж совсем буквально все понимать. Смысл в том, что при отделении не стоит и до маразма доходить. Это как с нормализацией - меру знать надо.

← →
ketmar © (2008-01-28 04:22) [129]

>[128] Семеныч (28.01.08 02:41)
а что такое «отделение до маразма»? нет, серьёзно. давай сначала определимся, а то сложно дальше говорить.

← →
Семеныч (2008-01-28 10:49) [130]

> ketmar © (28.01.08 04:22) [129]

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

Чтобы не залезать в дебри, возьмем самый простой пример отделения данных от гуи - датамодули. Один вариант - все компоненты доступа к данным лежат на датамодулях, все DB-контролы лежат на формах (будем считать, что в этом случае разделение полное). Другой вариант - датамодулей нет, все лежит на формах (будем считать, что в этом случае разделения нет совсем).

Когда разделения нет совсем - плохо. Хотя бы уже потому, что код визуалки смешивается с кодом бизнес-логики. Плохо обозримо, неудобно в поддержке и модификации, формы взаимосвязаны и т.п.

А когда когда разделение полное - хорошо? А вот это надо смотреть. Если несколько датасетов связаны какой-то относительно сложной бизнес-логикой (скажем, если в одном что-то выставлено, то в другом что-то нельзя удалять) - то есть смысл такие датасеты поместить в один датамодуль и в нем же написать нужный код. Тогда разделение с гуи есть гуд.

Но вот появляется какая-то маленькая табличка, которая будет редактироваться раз в год, с другими не связана, никаких сложных бизнес-правил не имеет. Для нее есть гуевый редактор, датасет и датасорс. Надо ли эти датасет и датасорс кидать на датамодуль, или их можно кинуть прямо на форму редактора?

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

Не читавший книг совсем швыряет все на форму и на вопрос "почему" отвечает - а на фига вообще нужны эти датамодули? Это другой маразм.

Человек же, который не только читает, но и еще думает, соображает так: хоть оно и положено, но нельзя же все стричь под одну гребенку. На фига для такой простейшей подзадачки, которая сложнее заведомо не станет, таскать еще и целый компонент (датамодуль)? Ресурсы - они все же не резиновые.

И тоже все кладет на форму. Но на вопрос "почему" имеет логичный ответ.

← →
isasa © (2008-01-28 11:01) [131]

Семеныч (28.01.08 10:49) [130]
:)
Я тут эта, извиняюсь, а куда класть то, вообще?
А если у меня еще не один поток? Здоровый датасет, сволочь, долго грузится. Нада зайчиков по форме пускать, что-бы не скучно было ...

← →
isasa © (2008-01-28 11:04) [132]

ЗЫ. С удивлением обнаружил, что большинство книг по программированию, не библия. И заветов не содержит ...

← →
Семеныч (2008-01-28 11:08) [133]

> isasa © (28.01.08 11:01) [131]
> а куда класть то, вообще?

А вот туда, куда задача диктует и здравый смысл с опытом подсказывают. Главное - в маразмы не впадать.

← →
Игорь Шевченко © (2008-01-28 11:19) [134]

Семеныч (28.01.08 01:59) [123]

> Есть таблица БД. Пишем невизуальный класс, который эту таблицу
> отображает на свои свойства. В нем же - метод валидации
> данных (поскольку он сам про себя все знает, пусть сам себя
> и проверяет). В нем же - проверки допустимости операций
> (методы типа CanBeModified). И все такие классы - потомки
> одного (а в нем - базовый функционал).
>
> Далее - пишем универсальный диалог редактирования таких
> классов. В его конструкторе есть параметр - экземпляр такого
> класса. Диалог создает свои контролы не из DFM, а динамически,
> используя RTTI полученного объекта. Когда диалогу нужно
> что-то проверить - вызывается нужный метод редактируемого
> объекта.
>
> Изменилась задача - вносим изменения в тот самый невизуальный
> класс. И все, код GUI не меняется. И разделение данных с
> GUI имеется. И кумира нет.

Я за подобную динамику отрывал бы руки. По самую голову.
Дабы неповадно было динамику писать

← →
Семеныч (2008-01-28 11:23) [135]

> Игорь Шевченко © (28.01.08 11:19) [134]

Так руки с головой можно и за статику отрывать. Причем столь же необоснованно, как и за динамику.

← →
isasa © (2008-01-28 11:23) [136]

Игорь Шевченко © (28.01.08 11:19) [134]

И я догадываюсь за что. :)

Через год, когда забудется "На фига я это сделал" в этой динамической RTTI каше(которую, кстати, можно наглядно отобразить) фиг чего найдешь.

← →
Игорь Шевченко © (2008-01-28 11:25) [137]

Семеныч (28.01.08 11:23) [135]

За статику отрывать - вообще одни безрукие останутся.

isasa © (28.01.08 11:23) [136]

> И я догадываюсь за что. :)

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

← →
Семеныч (2008-01-28 11:29) [138]

Есть объект. У него есть свойство с именем PropName типа Integer. Надо динамически создать визуальный редактор этого поля.

Ах, какая сложнейшая задача, не так ли?

← →
ketmar © (2008-01-28 11:33) [139]

>[130] Семеныч (28.01.08 10:49)
это вот называется «эклектика». прикольно, но неудобно. имо.

← →
isasa © (2008-01-28 11:34) [140]

Семеныч (28.01.08 11:29) [138]

Тут эта, динамически создается объект класса, а описать сам класс можно визуально в IDE или через ж... ручками. Что легче?

← →
Семеныч (2008-01-28 11:39) [141]

> isasa © (28.01.08 11:34) [140]

Описать ОДИН раз ручками (и ОДИН раз отладить), или до фига раз в IDE (а потом и еще много раз, когда новые редакторы появляться начнут), и КАЖДЫЙ редактор отлаживать.

Что легче? Где будет ошибок меньше?

>[141] Семеныч (28.01.08 11:39)
меньше ошибок будет, если один раз сделать свой редактор.

Семеныч (28.01.08 11:29) [138]

> Ах, какая сложнейшая задача, не так ли?

Это не сложнейшая задача. Это ненужная задача.

← →
Семеныч (2008-01-28 12:51) [144]

> ketmar © (28.01.08 12:00) [142]

Вот так и сделано (читай выше).

> Игорь Шевченко © (28.01.08 12:22) [143]

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

Ты нашу задачу знаешь? Ты архитектуру программы знаешь? Почему и зачем она именно такая - знаешь? Так как же ты можешь судить, что в ней нужно а что не нужно?

И (что интересно) - никаких "может быть". И никаких "потому что". Ненужная - и все. Без сомнений, без аргументации.

Я в восторге.

=================

Вообще, заявления типа "это так, потому что это так" на этом сайте встречаются нередко. Это такой стиль дискуссий здесь принят, что ли?

Ув. мастера - а вы, часом, не замастерились ли?

Все, достаточно. Уже неинтересно. Пойду-ка я лучше ненужную задачу себе придумывать.

Семеныч (28.01.08 12:51) [144]

А действительно задача ненужная. Редакторов свойств типа Integer как звезд на небе, готовых.

>[144] Семеныч (28.01.08 12:51)
«своего редактора» я выше не заметил.

а, да. я, конечно, имел в виду не «редактор свойств», а «конструктор форм».

> Есть таблица БД. Пишем невизуальный класс, который эту таблицу
> отображает на свои свойства.

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

> [57] Anatoly Podgoretsky © (27.01.08 19:54)

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

> Ketmar

> это он не пошутил. это у него привычка для production code
> так делать. потому что есть не падать с post mortem dump,
> то узнать, что там у заказчика произошло — невозможно.

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

> Palladin (28.01.2008 13:37:29) [149]

Разные приложения, разные требования.
Если приложение серверное, а зная наших админов, так они читать не будут, поскольку лень, мол и так работает, то послать оповещение, раз в сутки, обобщеное - мол есть 12 критических и 40 некритических сообщение благое дело.
Далее по вкусу или смотреть лог или запросить его по почте.

Delphi типы исключений. Найти похожие ветки