Всем привет.

Имеется к примеру вот такая процедурка(взято абстрактно):



Какие в ней вообще могут возникнуть ошибки? 

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

Предложения? 

Вот так можно  

А по другому и нельзя. Вопрос в том, какие могут быть ошибки?

У меня смысл ошибки заключался в том, что человек вызвал процедуру следующим образом:



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

Кстати, Rrader, подобные методы от тебя пошли насколько помню по нашему форуму   
И к тебе у меня вопрос:

Ты показывал такие примеры на WinAPI функциях. Как там обрабатываются значения типа этого PInteger(Nil)^ ?
Просто идет глушение ошибок или же есть какая-то проверка вроде:



???

И мне интересно - как еще можно поизвращаться с чем нибудь в этой простейшей процедуре? 

THandle, я когда увидел тему, я в шоке легком был. Потому что я зашел в клуб, чтобы создать подобную тему  Тоже про ошибку в функции. Эта функция, предложенная тобой, может еще в одном случае завалить программу. 

Я лишь напомнил, эта практика давно была известна многим программистам Delphi. Это как с последовательностью Фибоначчи, ее знали египтяне, а называется она по имени средневекового математика  

Ну, например, GetWindowThreadProcessId:

Просто проверка на не NULL (0). Функция получает указатель на входе. А теперь смотрим, что Delphi передает:



Добавлено через 3 минуты и 12 секунд

Что имеется в виду?

А что ты там хотел написать? 



Понятно, спасибо 



Имеется ввиду как раз вот такие случаи:



А так же при каких обстоятельствах они могут возникнуть 

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

Проверку на пустоту можно сделать так:

Если приведение типов использовать бездумно,  можно скольугодно много нагородить такого:

А это уже как повезет, может прокатить, а может и нет:
 Видимо товаристч действительно про WIN API начитался, там частенько можно вызывать какую-нибудь функцию дважды, в первый раз с nil, только для получения размера возвращаемых данных, а потом уже выделять память и передавать реальный указатель, но там, правда, специально оговаривается в документации, что так можно.

Ну так для таких случаев и прототип ведь другой используется. PInteger называется. А не var Integer.

Правило простое:
- Видим PInteger - вероятно, функция примет nil.
- Видим var Integer/out Integer - функция nil не примет.

Достаточно прозрачная логика. А var с nil - это кривейшая кривость. Всё равно что Self на nil проверять. Как ремни безопасности - пожалуйста. Как штатная логика - пристрелить на месте.

Наверно в книжках "Библия Pascal/Delphi/С/++/# для профессионалов"  об это не написано.
P.S. формально говоря ошибка то не в процедуре, а вне её.

CodeMonkey, все правильно. var - значит что параметр обязан быть, причем нужного типа.
Ассерты, конечно, есть, но на такое писать никаких проверок не хватит. Ну проверил на nil, и что? Он же получит отлуп и подаст PInteger(Form1)^ например.   Проверяйте!