http://forum.quik.ru Новое в теме Возврат nil из некоторых функций форума на сайте Форум QUIK [forum.quik.ru] ru http://backend.userland.com/rss2 Fri, 10 Apr 2026 11:45:23 +0300 Возврат nil из некоторых функций не отличить штатную отработку от ошибки в форуме Программирование на языке Lua.
Enfernuz, Добрый день,
      Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам,       что реализация пожелания признана потенциально целесообразной.       Если по результатам дальнейшего анализа, включающего юридические       аспекты, анализ на непротиворечивость с общей политикой компании,       никаких возражений не возникнет, мы постараемся включить Ваше       пожелание в план доработок при выпуске одной из следующих версий       нашего ПО.
25.12.2017 15:40:14, Zoya Skvorcova.]]> http://forum.quik.ru/messages/forum10/message28408/topic3071/ http://forum.quik.ru/messages/forum10/message28408/topic3071/ Mon, 25 Dec 2017 15:40:14 +0300 Программирование на языке Lua Возврат nil из некоторых функций не отличить штатную отработку от ошибки в форуме Программирование на языке Lua.
Добрый день,


====quote====
Enfernuz написал:
Т.е. на лицо некоторая непоследовательность в подходе к возвращаемым значениям-ошибкам. По науке, в Lua есть механизм error() для сигнализирования ошибок, но я осознаю, что могут быть разные причины его не применять. И если уж так, то пихать nil только в случае ошибок -- другие ситуации не должны возвращать nil.
Как-то так. Возможно, где-то что-то упустил, т.к. функций много, и не везде я при тестировании делал пометки, но что есть, то написал.
Нужно либо эти моменты получше задокументировать, либо переделать "по-феншую" (хотя тут, скорее всего, малой кровью не обойтись, т.к. уже написано немало кода с использованием существущего механизма).


=============
Ваше пожелание относительно единообразия возвращения ошибок в функциях зарегистрировано.  Мы постараемся рассмотреть его и  сообщить Вам результаты анализа. Впоследствии, по результатам анализа,  будет приниматься решение о реализации пожелания в будущих версиях ПО.


====quote====
Enfernuz написал:
Отдельно:
IsWindowClosed -- функция задокументирована так, что по  сути ожидать приходится возврата либо nil, либо true. Чем провинился  false? Имхо, false можно было возвращать, если окно есть, но не  закрылось (по каким угодно причинам); true -- окно закрылось; nil --  окно не найдено или ещё какая напасть.


=============
Ваше пожелание зарегистрировано.  Мы постараемся рассмотреть его и  сообщить Вам результаты анализа. Впоследствии, по результатам анализа,  будет приниматься решение о реализации пожелания в будущих версиях ПО.
20.09.2017 11:45:28, Stanislav Tvorogov.]]> http://forum.quik.ru/messages/forum10/message26760/topic3071/ http://forum.quik.ru/messages/forum10/message26760/topic3071/ Wed, 20 Sep 2017 11:45:28 +0300 Программирование на языке Lua Возврат nil из некоторых функций не отличить штатную отработку от ошибки в форуме Программирование на языке Lua.
Многие функции библиотеки в результате своей работы возвращают nil. Но есть такие, которые возвращают nil и в случае "нормального" (в логическом смысле) режима работы.
Например, функция SearchItems. Если передать ей коллбэк "function(t) return false end", то ожидая получить пустую таблицу на выходе (= пустой массив в Lua, "индексов, удовлетворяющих условию, не найдено"), на самом деле мы получаем nil. Тот же самый nil мы получим, если произошла ошибка в коллбэке. Тем самым, получив nil, сложно понять, не нашлось ли индексов по условию или это в коллбэке ошибка.

Ещё функции, где возникают подобные вопросы:
getMoneyEx -- что в случае ошибки во входных параметрах (например, передал nil в качестве всех параметров), что в случае просто отсутствия информации (допустим, указали валюту, которой нет на лимитах -- это ведь не ошибка?) возвращается nil. Т.е. непонятно, то ли в аргументах ошибка, то ли просто информация не найдена.
getDepoEx -- аналогично;
getFuturesLimit - аналогично;
getFuturesLHolding -- аналогично;
getSecurityInfo -- тут спорно, т.к. nil можно трактовать как отсутствие информации по переданной паре аргументов. Т.е. что nil, что {} в данном случае -- в принципе, одинаково можно понять. nil даже получше будет, наверное.

Например, есть функции, где отсутствие информации трактуется как "не nil", и где ошибочные ситуации не задокументированы:
getClassSecurities -- возвращает пустую строку;
getMoney -- возвращает параметризованную таблицу со значениями по умолчанию (нули);
getDepo - см.getMoney;
getCandlesByIndex -- возвращает ({}, 0, ""), если запросили несуществующих тег;
CalcBuySell - возвращает (0, 0), если передать nil'ы в качестве аргументов;
getParamEx -- возвращает таблицу, если намеренно передать "испорченные" аргументы;
getParamEx2 -- см. getParamEx;
getPortfolioInfo -- возвращает {};
getPortfolioInfoEx -- см. getPortfolioInfo;
getBuySellInfo -- см. getPortfolioInfo;
getBuySellInfoEx -- см. getPortfolioInfo.

Отдельно:
IsWindowClosed -- функция задокументирована так, что по  сути ожидать приходится возврата либо nil, либо true. Чем провинился  false? Имхо, false можно было возвращать, если окно есть, но не  закрылось (по каким угодно причинам); true -- окно закрылось; nil --  окно не найдено или ещё какая напасть.

Подводя итог, по факту имеем:
1) часть функций, где не задокументирован формат возвращаемых значений в случае ошибки, но всё-таки возвращающих не-nil (пустые таблицы, строки, ...);
2) часть функций, где формат возвращаемых значений задокументирован ("возвращает nil"), но его трудно отличить от ситуации, когда аргументы семантически верные, но по ним нет данных;
3) остальные функции, где формат возвращаемого значения в случае ошибки задокументирован и не nil (true/false, -1, ...).

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

P.S.
Функция SearchItems, по моим впечатлениям, страдает ещё от неверной работы фичи "если в коллбэке вернёте nil, то поиск индексов остановится и вернёт все подходящие индексы до этого момента + тот, на котором остановились": у меня почему-то SearchItems упорно возвращал nil, а коллбэк был что-то типа "function(t) if t.sec_code == 'AFKS' then return nil else return false end", при том, что этот же слегка изменённый коллбэк "function(t) if t.sec_code == 'AFKS' then return true else return false end" исправно выдавал массив из трёх элементов. Но этот момент я ещё потестирую отдельно на досуге. Написать всё-таки хотел не об этом, но побудила на написание поста именно она.
19.09.2017 03:54:48, Enfernuz.]]> http://forum.quik.ru/messages/forum10/message26721/topic3071/ http://forum.quik.ru/messages/forum10/message26721/topic3071/ Tue, 19 Sep 2017 03:54:48 +0300 Программирование на языке Lua