PResStringRec = ATResStringRec;
TResStringRec = packed record
Module: ACardinal;
Identifier: Integer;
end;
Если вы еще раз посмотрите на список конструкторов объекта Exception, вы увидите, что те из них, которые работают с ресурсами, имеют перегружаемую версию с параметром типа pResStringR.ee. Вы угадали правильно: они - для строк из resourcestring. А взглянув на приведенную выше структуру, вы увидите в ней поле identifier. Это то, что нам надо.
Чтобы у программиста, пользующегося resourcestring, голова не болела об уникальных идентификаторах ресурсных строк, среда Delphi берет на себя заботу об этом. Номера назначаются компилятором, начиная от 65 535 (smailint (-1)) и ниже (если рассматривать номер как тип Smaliint, то выше): 65 534, 65 533 и т. п. Сначала в этом списке идут несколько сотен resourcestring-констант, описанных в VCL (из модулей, чье имя заканчивается на const или consts: SysConst, DBConsts и т. п.). Затем очередь доходит до пользовательских констант (рис. 3.3).
С одной стороны, отсутствие лишних забот - это большой плюс; с другой стороны, разработчик не может задать строкам те номера, какие хочет.
Все остальное почти ничем не отличается от работы с "самодельными" ресурсами. Так выглядит перегружаемая версия конструктора нашего объекта
EExceptionWithCode:
constructor EExceptionWithCode .CreateResCode (ResStringRec:
PResStringRec);
begin
FErrCode := ResStringRec'\ Identifier;
inherited CreateRes (ResStringRec) ;
end;
Атак - возбуждение самой ИС:
resourcestrzing sErrorl = 'Error 1';
Raise EExceptionWithCode.CreateResCode(PResStringRec(SsErrorl)); Реэ/тьтягссрасотлкигоказанЕарис. 3.3.
Рис. 3.3. Результат обработки ИС типа EExceptionWithCode
Исключительная ситуация EAbort
ЕСЛИ ВЫ ВНИМаТеЛЬНО ПрОСМОТреЛИ КОД СИСТеМНОЙ Процедуры HandleException, то увидели там упоминание класса EAbort. ИС EAbort служит единственным - и очень важным - исключением из правил обработки. Она называется "тихой" (Silent) и отличается тем, что для нее обработка по умолчанию не предусматривает вывода сообщений на экран. Естественно, все сказанное касается и порожденных от нее дочерних объектных классов.
Применение EAbort оправдано во многих случаях. Вот один из примеров. Пусть разрабатывается некоторая прикладная программа или некоторое семейство объектов, не связанное с VCL. Если в них возникает ИС, то нужно как-то известить об этом пользователя. А между тем прямой вызов для этого функции showMessage или даже MessageBox не всегда оправдан. Для маленькой и компактной динамической библиотеки не нужно тащить за собой громаду VCL. С другой стороны, в большом и разнородном проекте нельзя давать каждому объекту или подпрограмме самой общаться с пользователем. Если их разрабатывают разные люди, такой проект может превратиться в вавилонскую башню. Тут и поможет EAbort. Эта исключительная ситуация не создается системой - ее должен создавать и обслуживать программист.
Применение EAbort - реальная альтернатива многочисленным конструкциям if., then и тем более (упаси боже!) goto. Эта ИС не должна подменять собой другие, вроде ошибки выделения памяти или чтения из файла. Она нужна, если вы сами видите, что сложились определенные условия и пора менять логику работы программы.