В предыдущем посте мы рассмотрели основы ошибок и обработки ошибок в Балерине, включая тип error, создание значений ошибок, panic, trap, check, checkpanic и т. Д.

В этом посте мы рассмотрим более сложные концепции, в том числе

  • определение и использование настраиваемых типов ошибок
  • неизменность ошибок и типовой тест на ошибки

Определение настраиваемых типов ошибок

Хотя работа с универсальным типом ошибки проста, довольно часто вам нужно более точно указать, какие типы ошибок будут возвращать ваши функции.

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

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

Пользовательский тип ошибки можно определить, указав тип причины и, при необходимости, тип подробностей.

  • тип причины должен быть подтипом типа string
  • тип детали, если он не указан, по умолчанию будет
record {|
   string message?;
   error cause?;
   (anydata|error)...;
|};

Если указано, это должна быть запись, являющаяся подтипом указанного выше.

Теперь давайте определим пользовательскую ошибку с конечным набором строк в качестве возможных причин и пользовательской записью в качестве подробной записи.

Ошибка типа FileDeletionError, определенная на L16, может быть определена только с указанием «FileNotFound» или «InsfficientPermission» в качестве причины. Все остальное приведет к ошибке компиляции. Более того, поля message и code теперь также являются обязательными для описания ошибки.

Различные сценарии ошибок в приведенном выше примере также могли иметь свои собственные ошибки.

Ошибки неизменны

Любые и все значения ошибок в Ballerina неизменны. Таким образом, когда вы обращаетесь к причине, деталям или трассировке ошибки, вы знаете, что она не была изменена после создания. Кроме того, если вы попытаетесь обновить ошибку, это приведет к панике!

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

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

Вот и все для этого поста! :)

В следующем посте мы рассмотрим шаблоны привязки ошибок и шаблоны соответствия.