AIF vendTable.validateField() бага или фича ?

[Logger]

Привет.
Обнаружил в
\Data Dictionary\Tables\VendTable\Methods\validateField
странный код

boolean validateField(fieldId p1)
{
...
    boolean     ret;
    ;
    //AIFFault Mesgs
    switch (p1)
    {
        case fieldnum(VendTable, InvoiceAccount):
            if (this.InvoiceAccount && !VendTable::find(this.InvoiceAccount))
            {
                ret =  AifFault::checkFailedLogFault(strfmt("@SYS120870", fieldid2name(tablenum(VendTable), p1), this.InvoiceAccount), #InvalidInvoiceAccount);
            }
        break;
...
    }
//AIF Fault Mesgs end here
...
    ret = super(p1);

    if (ret)
    {
        switch (p1)
        {
...
            case fieldnum(VendTable, CreditMax) :
                if (this.CreditMax < 0)
                {
                    ret = checkFailed("@SYS69970");
                }
...
        }
    }
    return ret;

код процитирован для ax2009, но в 2012-й аналогично.

1. ret в начале метода никак не инциализируется, т.е. имеет значение false
2. Затем идет куча проверок для AIF с присвоением в ret значения false в случае ошибки.
3. Затем идет вызов super() c перетиранием значения ret (!) т.е. игнорируются найденные на шаге 2 некорректности в заполнении полей (хотя какие они найденные, когда ret инициализровался как false).
4. Затем обычные проверки значений полей.

Вопрос, что это такое ?
Это досадная опечатка в коде, приведшая к тому что не работает целый кусок по валидации значений (только пишет сообщения в инфолог и в AIF)
или так и было задумано (валидация в принципе на super() должна была отработать, но она только в инфолог сообщения шлет, а в AIF - нет. т.е. возможно этот код просто досылал интересующие автора сообщения в AIF) ?

[Link]

Судя по коду, значение ret перед super неважно. Т.е. в принципе присваивание ret до super можно убрать, что бы не вводить в заблуждение. Может копипаст такой.

[gl00mie]

Думаю, затея разработчиков AIF была примерно такая:

• штатные проверки на обязательность заполнения полей и по relation'ам таблиц выводят подчас невнятные сообщения, типа значение "такое-то" не найдено в связанном справочнике сяком-то
• программный код, в отличие от пользователя, с большим трудом по текстовому сообщению может понять, какую именно проверку не прошел поставщик, коду больше подходят некие уникальные идентификаторы ошибок
• при создании/изменении поставщиков через AIF, в т.ч. с использованием Excel Add-in, очень важно понимать, в каком именно поле ошибка, а из сообщений это не всегда очевидно

Значит, решили разработчики AIF, надо продублировать проверки ядра и:

• явно указывать, в каком поле ошибка
• добавить некий уникальный идентификатор ошибки (см. библиотеку макросов #VendFaults)

Т.е. все перечисленные проверки для AIF, дублирующие проверки ядра, по сути нужны, чтобы добавить метку поля в текст ошибки и уникальный идентификатор ошибки - в контекст AifFault. За счет уникального идентификатора ошибки становится возможно "различать" в коде без интеллектуального разбора сообщений инфолога. А результат этих проверок действительно не важен, ведь они - лишь костылик для толкования и детализации результатов проверок в ядре.