Цитата:
Сообщение от
gl00mie
пару специализированных классов для проверки наиболее часто встречающихся условий и утверждений
В этом и беда универсальных методов - часто встречающиеся они обрабатывают... А вот с отсальными приходится мучаться.
Цитата:
Сообщение от
gl00mie
С ним идея была в том, чтобы в сообщениях на запись практически любой таблицы можно было ссылаться с помощью одного placeholder'а (%1), но чтобы описание при этом получалось необходимым и достаточным для идентификации записи, о которой идет речь: если это SalesTable, то чтобы был указан SalesId, если CustTable/VendTable - чтобы там был AccountNum, если CustTrans/VendTrans - чтобы обязательно были Voucher и TransDate и т.п., ну и чтобы везде был RecId, как в отладчике.
мне кажется, что вместо такой хотелки стоит рассмотреть следующий стандартный подход.
- ВСЕГДА надо писать setprefix("информация о том, что обрабатываем в данный момент - информация об источнике")
- сообщения об ошибках должны содержать только информацию об ошибке, но не должны содержать информацию об источнике ошибки
- (опционально) вместо вывода recid всегда юзать SysInfoAction
при таком подходе информация об источнике возникновения выводится там, где она реально имеется. при таком подходе эту информацию не нужно спускать на нижние уровни.
если юзать SysInfoAction то пользователю не нужно будет перевбивать в поиск recId - достаточно просто нажать на кнопку в инфологе.
беда в том, что люди не юзают даже стандартные подходы. Даже в Майкрософте.
=================
краткий совет - если не хватает информации об источнике ошибки, то всего-лишь добавьте setprefix в циклы верхнего уровня.