Во-первых, Delphi не хватает отладочного режима для стека. MS VS C++, равно как и (что особенно обидно!) C++ Builder (через CodeGuard) имеют эту возможность, а Delphi - нет. Суть возможности заключается во вставке отладочного кода, который проверяет целостность стека. Примерно так же, как это делает менеджер памяти в отладочном режиме для динамической памяти (кучи).
Я не знаю, почему в Delphi до сих пор нет этой возможности. Есть даже миф, который говорит, что в Delphi не бывает ошибок переполнения буфера (buffer overflow). Да, хотя подобный класс ошибок с точки зрения безопасности не очень-то применим к Delphi (поскольку обычно все буфера выделяются в динамической памяти), но всё же такие ошибки бывают, но уже не как часть попыток хакера взломать программу, а как ваши собственные баги. Проблема в том, что когда такие ошибки всё же случаются (а они случаются, причём не так уж редко), у вас нет ни единого шанса. Ваша программа просто вылетит без единого сообщения об ошибке и вы ничего не сможете с этим сделать.
Я отправил запрос на эту возможность в Quality Central. Можете проголосовать.
Во-вторых, в Delphi не умеет загружать/использовать минидампы. Минидамп - это файл, содержащий в себе "слепок" состояния программы в какой-то момент времени. Они используются/создаются ОС при синем экране смерти, а также при вылетах программы (их собирает WER/Dr.Watson), кроме того, их можно создавать руками по запросу.
Чем полезен минидамп? Тем, что он может точно воспроизвести ситуацию с ошибкой. Пусть ваша программа валится с ошибкой у клиента. Что вы будете делать? Ну, вы можете попробовать использовать трейсер исключений. Он создаст ваш стек вызовов и отчёт по ошибке. Но часто этой информации не достаточно. Вы не видите ни переменных, ничего такого. Но если вместо этого вы бы создавали минидамп, то вы смогли бы сохранить состояние программы в момент ошибки. Тогда позже, когда вы получаете минидамп, вы загружаете его и программу в отладчик и - вуаля! В отладчике перед вами будет программа ровно в том же состоянии, что в момент вылета. Вы не можете пустить её на выполнение, но вы можете анализировать её любым способом, как вы обычно работаете с отладчиком, когда программа стоит на паузе. Анализировать переменные, потоки, стеки и т.п.
К сожалению, отладчик Delphi не умеет загружать минидампы :( А жаль. Такая полезная возможность.
Голосовать тут.
В третьих, в Delphi из коробки нет возможности внедрять/создавать отладочную информацию в форматах, распознаваемых Microsoft-скими утилитами. Вот, например, как выглядит работающий поток Delphi-программы в Process Explorer:
Для Project.exe нам доступны только двоичные смещения. Никакого текстового описания. Хотя для системных библиотек оно есть (*). Не слишком-то удобно, правда?
За эту возможность голосовать тут.
Примечания:
(*) Для этого я сконфигурировал Process Explorer на автоматическую загрузку отладочной информации (Options/Configure symbols):
Для этого вам также нужно будет установить Microsoft Debugging Tools.
Как всегда ты пишешь о таких вещах, которые мне и в голову не пришло бы сформулировать, но читая их я начинаю понимать что с этими штуками работа была бы намного проще.
ОтветитьУдалитьПо мне так не хватает тэсторов и активности в исправлении ошибок.
ОтветитьУдалитьВот тут занялся dbExpress:
БД феноменальносложная аж 4 таблицы :)
Ошибки прямо на поверхности, такое впечатление, что по мере внесения изменений в код его даже не запускают.
Отправил 3 багрепорта.
Не говоря уже о странностях с которыми лень разбираться, и совершенно нечленоразделных текстах исключений.
Еще хотелось бы поиметь интерфейсы как часть языка.
ОтветитьУдалить