Debug - как заставить Delphi точно указать на строку кода вызывающую ошибку?

[delphicoding]

Здравствуйте!
В замороченном проекте с кучей кода и окон в одном месте постоянно выскакивает "Could not convert variant of type (Null) into type (Double)". (Небольшая ремарка - конечно это само по себе бред полный, тк Null это "пусто" и при переделке "пусто" в любой формат хоть строки, хоть числа, чего угодно всё равно должно получиться "пусто", ну да ладно, оставим это на совести разработчиков Delphi.) Проблема том, что в месте где возникает ошибка происходит подряд целая цепь событий: создание окна, загрузка данных, выбор данных, создание другого окна, передача параметров, обновление данных БД, формирование отчёты FastReport. Много всего и куча данных - понять что где глючит не зная места и данных невозможно.

Пробовал ставить BreakPoints, запускать в режиме Trace To Next Source Lines, жать break когда выскакивает ошибка, итд - без толку, ошибка просто появляется и откуда берётся непонятно! (Понятно лишь, что при нажатии на кнопку, но там такое кол-во сразу выполняется процедур и данных, что ого-го.)

Если ли какой-то способ заставить Delphi чётко указать на строку кода, в которой возникает ошибка и желательно отобразить переменную и данные в удобоваримом виде которые вызывают ошибку?

PS Попутно вопрос по датам - если при вводе Дата не указана, то может ли она везде (Delphi,Firebird,FastReport) быть null? или null в контексте Даты вызывает ошибку? Как тогда передавать "дата не указана", чтобы в БД сохранилось как null?

[veniside]

Если ошибка в недрах фастрепорта, строку оно не покажет, максимум CPU. Можно включить компиляцию с отладочными версиями модулей (Use debug .dcus), и смотреть по стеку, кто кого вызвал. Но, имхо, толку от этого не много. Выяснится, что у вас где-то в отчёте поле с датой, а в базе Null. Ну и чем поможет вам конкретная строка? Настройки отчета надо менять, скорей всего.

> E2010 Incompatible types: 'TStrings' and 'string'.

Ну дык, TStrings — это список строк, а не строка. У него есть свойство Text, если нужны все строки слепленные оттуда.

> конечно это само по себе бред полный...всё равно должно получиться "пусто"

Null для того и ввели, чтобы отличать пустую строку от строки, которую не ввели.

Не в обиду, но ваши ремарки очень напоминают одного известного литературного героя )

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

[Человек_Борща]

эмм MadExcept, EurekaLog?
Отладка построчно?

[delphicoding]

Выяснится, что у вас где-то в отчёте поле с датой, а в базе Null. Ну и чем поможет вам конкретная строка?

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

Null для того и ввели, чтобы отличать пустую строку от строки, которую не ввели.

В БД кажется разницы нет... null и есть пустота. Да и все поля для ввода вряд-ли в данном контексте могут иметь два разных состояния - всяко ведь "пусто"... ну и совсем никакого смысла различать "пусто" по разным классам - это вообще шиза уже.

Отладка построчно?

Таки делал, не показывает строку точно... просто вдруг возникает ошибка. Точнее видно, на какой строке остановилось выполнение программы, там строка вызывающая другую процедуру и передающая в ту процедуру около 10 параметров... даже если предположить самое вероятное - что проблема в присвоении одному из параметров вызываемой процедуры данных другого формата, всё равно остаётся совершенно неясным какой из параметров вызывает ошибку! и уж тем более непонятно какие там вдруг возникли такие неправильные данные?!?!?!

На*уй нужен такой дебагинг не показывающий значений и названий переменных ?!

[Человек_Борща]

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

[delphicoding]

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

[spamer]

На*уй нужен такой дебагинг не показывающий значений и названий переменных ?!

Вот не нужно тут выражаться в таком тоне, если не разобрались до конца...

По теме, построчная отладка практически всегда дает результат...Следовательно, инструмент в "зубы" и искать ошибку...И да, как говорили, на крайний случай можно EurekaLog воспользоваться...

как же можно узнать имя переменной и значение, которое вызвало ошибку?

Ставим бряку в месте, где возникает ошибка и пытаемся понять, что там не так (наводим на переменные и получаем их значения или же Ctr+F7)...тем более, что предположительно уже известно место ошибки, исходя из этого:

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

вот заходим в ту процедуру и смотрим чего там происходит такого...

[delphicoding]

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

вот заходим в ту процедуру и смотрим чего там происходит такого...

Напоминает "после сборки обработать напильником"... пфф...

Придумал как можно проверить, только не знаю как это реализовать... вопрос разумеется тупой - есть юнит DataModule, то есть без формы, в нём много чего происходит, а на выходе должен быть заполнен Datasource данными. Как можно из этого DataModule при помощи чистого кода создать нечто вроде текстового окна с кнопкой ОК/Закрыть и залить в это окно или некий графический объект все данные из Datasource (или Dataset) - чтобы наконец таки проверить все значения...

[Пепел Феникса]

Напоминает "после сборки обработать напильником"... пфф...

а вы думали что программирование как детский конструктор лего?

что именно вызвало ошибко и как называется эта переменная - неизвестно...

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

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

ShowMessage(Param)

(конвентирование если нужно напишите, это не холивар, просто на заметку)

Как можно из этого DataModule при помощи чистого кода создать нечто вроде текстового окна с кнопкой ОК/Закрыть и залить в это окно или некий графический объект все данные из Datasource (или Dataset) - чтобы наконец таки проверить все значения...

отладчиком итак это можно сделать(Ctrl+Click), да и при наведении итак покажет(у меня все показывало), + можно еще через инспектор наблюдать.
ну а если хотите сами, то создаете форму с мемо, и заполняете.

[chertovich]

Имея опыт работы с наборами данных, могу предположить что проблема в нем.
На счет "маркера" Null, в наборе данных, при при редактировании поля записи, если в нем не содержится символов то функция возвращает True при вызове IsNull.
Возможные ошибки в методе GetFieldData класса TDataSet (набора данных). FastReport и др. компоненты используют БД, а именно набор данных, который содержит ошибки. Советую найти/написать (не советую, пару выброшенных месяцев) набор данных. какую СУБД и набор данных используете?
Хотелось бы задать автору еще один вопрос: проект уже относительно большой, как Вы пишите программу, без тестирования каждой своей подпрограммы?
На счет отладки программы: знания места, которое вызвало исключительную ситуацию не всегда даст однозначное решение устранения ошибки, но дает программисту повод задуматься в эти слова...