В каждый вызов каждого метода каждого класса приходится передавать этот IStatus, а потом его анализировать, преобразовывать и т.п. Довольно утомительно, не так ли? Да и интерфейс захламляется. Ни у кого не возникало желания выкинуть этот обычно бесполезный мусор?

Можно сделать например так:
1) Каждый объект имеет статус.
2) Статус сбрасывается в начале вызова каждого метода и методы могут сохранить в него записи об ошибках, предупреждениях и просто информацию.
3) Между вызовами методов этот статус можно получить как reference-counted объект и использовать либо сразу либо позже. А можно просто выкинуть smart pоinter на него как исключение.
4) Чтобы решить а стоит ли вообще получать этот статус, каждый объект возвращает ODBC-образный код.

Так ведь будет гораздо проще, не правда ли?..

Симонов Денисоб этом раньше думать надо было. Ты думаешь на стадии RC2 изменять
API?
Естественно нет, я не думаю его изменять. Я думаю о реализации альтернативы для
внутреннего употребления.
Posted via ActualForum NNTP Server 1.5

Предположим, во время выполнения некоторой операции что-то пошло не совсем так как нужно и
в статус объекта были занесены некоторые warning-и. А потом всё вообще пошло плохо и
возникла ошибка.

Вопрос: должна эта ошибка выдавить из статуса уже лежащие там предупреждения или сложиться
рядом с ними?
Posted via ActualForum NNTP Server 1.5

Симонов Денисесли этот warning ранее не обработан, то почему бы и не выдавить.
Если операция ещё не вернулась в вызывающий код, он и не может быть обработан. Например,
функция isc_attach_database() сначала распарсила dpb, нашла там пару кривоватых
(устаревших) значений, сообщения о которых и занесла в статус-вектор. А потом она
обломилась, например, на отсутствии файла БД. И вот тут-то и возникает вопрос: надо
пользователю знать, что у него в dpb фигня была написана или это уже совершенно пофиг.
Posted via ActualForum NNTP Server 1.5

DarkMasterИначе в приведенном тобой сценарии нужно будет что-то вроде оценки "если
все уже плохо, то надо проверить насколько плохо" (оценка веса ворнинга).
Назачем? 99% софта ворнинги вообще счастливо игнорируют или даже не пытаются обнаружить. В
том числе и потому, что в текущем API нет средств для индикации их наличия. И я бы их
вообще с радостью извёл как класс, но остальные разработчики почему-то этого мнения не
разделяют.
Posted via ActualForum NNTP Server 1.5

Dimitry SibiryakovМожно сделать например так:
1) Каждый объект имеет статус.
.... и это полностью подрывает возможность одновременного использования одного объекта из
разных потоков: параллельные вызовы методов приведут статус объекта в неопределённое
состояние. И мутексом это уже не разрулить: его пришлось бы держать захваченным пока
вызывающий код не получит статус последнего вызова, чего может и не произойти.
Posted via ActualForum NNTP Server 1.5