ИМХО, neal прав на все 100%. Лично я бы подписался практически под каждым его словом...
Shark, Вы просто не совсем верно поняли одну из фраз, на которую отреагировали следующим образом: "Пользователь, изучающий значения переменных." По-видимому, имелось в виду, что именно программер придет и будет смотреть переменные. При удаленном сопровождении этот вариант, конечно, не рассматривается.

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

Вот кусок из лог-файла ошибок:

____27.03.04 (21:13:50)______CodeDeveloper: IvanScar______
Error : #10001 + vbObjectError (-2147211503) (Нарушена логическая целостность системных данных)
Error Source:
Help Source: KUBGridHelp.hlp (Context: 10)
Error Code : KscKUBGrid.SysFixGridSettingData (C:\Системные Решения\Mdb\KUBGridLib.mdb)
Parametrs : 0; 127;
Machine/User: Unknown/Unknown (Informed about error: True)

Из этого сообщения я могу узнать:
- когда и в какое время произошла ошибка;
- кто писал данный участок кода;
- какая ошибка (ее код и описание) и где (модуль, функция, файл) произошли;
- какие параметры были на входе процедуры (первый равен нулю, второй - 127);
- на какой машине и во время работы какого пользователя произошла ошибка и был ли этот самый пользователь проинформирован о возникновении исключения.

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

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

Но лично я (и это всего лишь мое мнение, мой стиль программирования, который я, конечно, никому не навязываю) в особенно ответственных местах, например в коде, реализующем бизнес-логику, ни за что не доверюсь некому мифическому номеру строки. Все исключительно на "генерации ошибок". Т.е. сложная, "много-ходовая" бизнес-транзакция разбивается на отдельные "проводки", каждая из которых реализована в своей функции, которая, в свою очередь, умеет справляться с возникающими ошибками или абсолютно информативно (что, где, по какой возможной причине) сообщать о возникшей ошибке как мне (через лог-файл), так и вызвавшему ("старшему" в иерархии транзакции) коду, который со временем (после каждой неожиданной ошибки обычно ведь вносятся изменения в программу, способные эту ошибку правильно обработать) становится довольно "интеллектуальным" и кое-что в бизнес-данных способен либо поправить самостоятельно, либо в диалоге с пользователем.
Кроеме того, абсолютное большинство ошибок, о которых мне сообщает приложение "придуманы" мной, а не MS! Т.е. ошибки типа "Деление на ноль" или "Тайп мисматч" практически никогда не попадают в лог-файл ошибок, ибо вместо них обработчики ошибок загоняют некую более полезную информацию в контексте выполняемой задачи. Например, в моем предыдущем посте сообщение об ошибке выглядит как "Нарушена логическая целостность системных данных", хотя, на самом деле, произошла (или даже НЕ произошла, а просто была логически "вычеслена") некая другая ошибка, и вот на основе данной ошибки мой "интеллектуальный" код запускает отдельную процедуру, которая "шерстит" эти самые "системные данные", пытаясь их исправить - либо исправляет некорректные данные значениями по умолчанию, либо спрашивает у юзера, либо лезет в архив. Положиться в данном случае на номер строки я не могу, ибо... хм... зыбко как-то...

Еще раз замечу, что в принципе, все это дело вкуса...

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

Shark> Но Вы ответили в стиле "А нафиг тебе это ваще?" Я и отреагировал соответственно. МНЕ НАДО.
МНЕ НАДО? Хм... А как же на счет вот этого:
gorobets dima: Короче есть вариант когда нужно сгруппировать все 3 таблицы.
Shark: Заведи одну табличку и не парься.
Человеку тоже было надо!*

Shark> Для этого придется при ошибке записать в лог снимок БД:-) В большинстве случаев, как раз, ошибка не воспроизведется (но бывают и исключения)
Возможно, у Вас всё именно так и происходит - все ошибки которые возникают, основаны на содержимом БД. Я не хочу озвучивать свои выводы о получаемых в результате проектах, а просто приведу статистику из своей практики. Львиная часть времени и "кода" лично у меня и моих знакомых программистов уходит на интерфейс и различные "сервисы". В большинстве своем этим самым "интерфейсам" и "сервисам" абсолютно безразлично, какие данные отображать. Ну а к "движкам данных" вообще подход особый.**

Shark> У меня где-то написано, что я пишу только номер строки?
Перечитывать не буду, ибо здесь не форум лингвистов или писателей-литераторов. Т.е. я "читаю" мысли, а не слова. И если слов таких небыло, то конечно извиняюсь, был не прав.

Shark> Это правда. Например случай Неал, когда из проекта (если его можно так назвать) даже не выброшены исходники , и предполагается, что автора можно позвать, и для этого даже специальная кнопка в обработчике ошибок.
Ндаааааа... AlTis, который вообще напару с клиентом по аське искал ошибку методом пошаговой отладки вообще полный .... хм... ??? Да? А ведь он в данном топике Ваш союзник, вроде как :) Круто вы даже со своими сторонниками обходитесь...***


Shark> Мне кажется, что для этого "другого" случая ваще не надо никаких обработчиков, тк стандартный эксесный+прибегающий автор дают лучшую функциональность.
Браво! БРА-ВО!!! //Никаких комментариев...****

Shark> Впрочем, заканчиваю пилить опилки:-)
100% за! :) //отвалился с темы...

--------------------
Примечания:
* - возможно развитие темы до 20 строк текста.
** - по поводу "движка данных" уже была представлена информация, при этом возможно практически безграничное развитие темы с приведением мнения супер-авторитетных спецов (путем цитирования их книг, статей и других трудов);
*** - непредоставление исходников удаленному клиенту (в случаях с некоробочными продуктами) вообще отдельная тема, которую, боюсь, обсуждать бессмыслено по ряду причин.
**** - просто никаких комментариев, ибо если этого не понятно вот просто так без объяснений, то объяснить будет невозможно...