В предыдущем посте мы рассмотрели основы ошибок и обработки ошибок в Балерине, включая тип error
, создание значений ошибок, panic
, trap
, check
, checkpanic
и т. Д.
В этом посте мы рассмотрим более сложные концепции, в том числе
- определение и использование настраиваемых типов ошибок
- неизменность ошибок и типовой тест на ошибки
Определение настраиваемых типов ошибок
Хотя работа с универсальным типом ошибки проста, довольно часто вам нужно более точно указать, какие типы ошибок будут возвращать ваши функции.
Более того, хотя вы можете буквально указать любую строку в качестве причины ошибки, когда дело доходит до реальных сценариев, обычно существует предопределенный набор причин ошибки.
Кроме того, хотя отображение подробностей универсального типа ошибки представляет собой открытую запись с необязательными полями, вам может потребоваться обязательное отображение подробностей ошибки, чтобы оно содержало дополнительную информацию (например, код ошибки).
Пользовательский тип ошибки можно определить, указав тип причины и, при необходимости, тип подробностей.
- тип причины должен быть подтипом типа
string
- тип детали, если он не указан, по умолчанию будет
record {| string message?; error cause?; (anydata|error)...; |};
Если указано, это должна быть запись, являющаяся подтипом указанного выше.
Теперь давайте определим пользовательскую ошибку с конечным набором строк в качестве возможных причин и пользовательской записью в качестве подробной записи.
Ошибка типа FileDeletionError
, определенная на L16, может быть определена только с указанием «FileNotFound» или «InsfficientPermission» в качестве причины. Все остальное приведет к ошибке компиляции. Более того, поля message
и code
теперь также являются обязательными для описания ошибки.
Различные сценарии ошибок в приведенном выше примере также могли иметь свои собственные ошибки.
Ошибки неизменны
Любые и все значения ошибок в Ballerina неизменны. Таким образом, когда вы обращаетесь к причине, деталям или трассировке ошибки, вы знаете, что она не была изменена после создания. Кроме того, если вы попытаетесь обновить ошибку, это приведет к панике!
Это также означает, что типовой тест всегда является проверкой на предмет наличия ошибки. Вы можете определять пользовательские ошибки, использовать конструкторы косвенных ошибок и т. Д., Но когда выполняется проверка типа, единственные проверки заключаются в том, принадлежат ли причины и подробные типы значения ошибки к типу, по которому проводится проверка.
По сути, это означает, что не имеет значения, где, когда и как была создана ошибка, значение ошибки будет принадлежать определенному типу ошибки, если сопоставление причин и деталей относится к ожидаемым типам.
Вот и все для этого поста! :)
В следующем посте мы рассмотрим шаблоны привязки ошибок и шаблоны соответствия.