Блог

При введении новых типов исключений я всегда, но не уверен, как это сделать правильно. Существует ли общее соглашение? Как вы это делаете?

Меня интересует область, в которой вы их упорядочиваете (храните их в модуле, в котором они используются? Есть модуль на уровне компонента? Уровень пакета? Приложение?)

Это также влияет на именование. Какой объем контекста вы включаете? Что лучше — сделать их очень специфичными (например, EPersonIDNotFoundError) или попытаться сделать их повторно используемыми (например, ENotFoundError)?

А как насчет суффикса «Ошибка» — когда я должен его добавить, а когда оставить? Я не вижу логики, например, в Classes.pas :

   EWriteError = class(EFilerError);
  EClassNotFound = class(EFilerError);
  EResNotFound = class(Exception);
  

Единственное реальное соглашение, о котором я знаю, это ставить перед ними префикс E . Я действительно не придавал этому особого значения в прошлом, но теперь, когда я думаю об этом, мне кажется, что оба Error и Exception обычно используются в качестве постфикса. Если вы смешаете их, я бы сказал, что это Exception относится к чему-то, что неожиданно выходит из строя, например, к разорванному соединению или файлу, который оказывается нечитаемым, в то время как ошибка больше связана с неправильным вводом, например, ожидалось число, но кто-то набрал текст.

VCL, похоже, тоже следует определенным соглашениям, но, похоже, добавляет постфикс только в том случае, если без него это было бы непонятно и ошибка, например

Ошибка эконовертера, Ошибка эматерра, ошибка Эварианта

против

Нарушение доступа, EInvalidPointer, EZeroDivide

Последние описывают саму ошибку, где первому списку нужен постфикс, чтобы указать ошибку в определенном процессе или объекте.

Эти примеры находятся в SysUtils, может быть, вы сможете взглянуть там, потому что он содержит много классов исключений, а также базовые классы для еще большего количества исключений. Очень немногие из них заканчиваются на Exception , за исключением некоторых очень специфических ошибок, с которыми вы действительно надеетесь никогда не столкнуться, таких как EHeapException и ESafecallException.

При создании нового исключения я делаю его доступным для всего приложения. Я начинаю с самой подробной ошибки до самой общей, например class (исключение), и называю их соответственно.

Итак, в вашем примере я бы использовал EPersonIDNotFoundError, ENotFoundError, Exception.

Это действительно зависит от того, сколько деталей вы хотите получить из своих сообщений об ошибках и что вы включаете в свой журнал (если вы ведете журнал ошибок)

Обычно для простых приложений вы можете обойтись исключением.Создать(‘ErrorMessage’). Где исключения становятся мощными, так это способность определять тип требуемого ответа, просматривая класс. Delphi уже делает это с помощью процедуры прерывания, которая вызывает EAbort. EAbort «особенный» в том смысле, что он не вызывает «ошибку» как таковую, т. е. это своего рода «молчащее» исключение. Вы можете использовать это специфичное для класса действие для проверки исключения и выполнения разных действий. Вы могли бы создать EMyWarning, EMyVeryNastyError и т.д., Каждый из которых произошел от базового типа исключения.

Кроме того, вы можете определить новый класс исключений, чтобы передавать больше информации в точку, где исключение захвачено. Например, с помощью кода (не отмечен):

 EMyException = class( Exception )
  constructor Create( const AErrorMessage : string; AErrorCode : integer ); reintroduce;
PUBLIC
  ErrorCode : integer
end;

constructor EMyException.Create( const AErrorMessage : string; AErrorCode : integer );
begin
  inherited Create( AErrorMessage );
  ErrorCode := AErrorCode;
end;
  

Теперь у вас есть возможность задать ‘ErrorCode’ при возникновении исключения, и он будет доступен при перехвате исключения. Исключения довольно мощные.

В какой области их упорядочивать?

Используйте один модуль для всего приложения, где вы пытаетесь разместить самые общие исключения. Все остальное передается в модуль, где генерируется исключение. Если вам нужны эти исключения в других блоках, переместите их в общий блок, используемый подсистемой, над которой вы работаете.

Как насчет именования?

Попробуйте создать один или два уровня «общих» исключений, подобных ENotFoundError . Поместите их в глобальный файл приложения. Не слишком старайтесь обобщать, потому что вы не можете знать, какое исключение появится позже, требуя, чтобы вы все изменили. Создавайте специализированные исключения на уровне модулей, наследуя от глобальных.

Как насчет постфикса «Ошибка»?

Перестаньте думать об этом. Добавьте это. Если это не звучит глупо.