Файл: Язык программирования Rust.pdf

Скачать файл (7,02Мб)

Заказать решение

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 11.01.2024

Просмотров: 1156

Скачиваний: 5

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Недействительные ссылкиВ языках с указателями легко ошибочно создать висячий указатель — указатель,ссылающийся на место в памяти, которое могло быть передано кому-то другому после освобождения этой части памяти, сохраняя при этом указатель на неё. В Rust, напротив,компилятор гарантирует, что ссылки никогда не будут висячими: если у вас есть ссылка на какие-то данные, компилятор убедится, что данные не выйдут за пределы области видимости до того, как это сделает ссылка на них.Давайте попробуем создать висячую ссылку, чтобы увидеть, как Rust предотвращает их появление с помощью ошибки во время компиляции:Файл: src/main.rsЗдесь ошибка:Это сообщение об ошибке относится к особенности языка, которую мы ещё не рассмотрели: времени жизни. Мы подробно обсудим времена жизни в главе 10. Но если вы не обращаете внимания на части, касающиеся времени жизни, сообщение будет содержать ключ к тому, почему этот код является проблемой:fn main() { let reference_to_nothing = dangle(); } fn dangle() -> &String { let s = String::from("hello"); &s } $ cargo run Compiling ownership v0.1.0 (file:///projects/ownership) error[E0106]: missing lifetime specifier --> src/main.rs:5:16 | 5 | fn dangle() -> &String { | ^ expected named lifetime parameter | = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from help: consider using the `'static` lifetime | 5 | fn dangle() -> &'static String { |

Определение и инициализация структурСтруктуры похожи на кортежи, рассмотренные в разделе "Кортежи", так как оба хранят несколько связанных значений. Как и кортежи, части структур могут быть разных типов.В отличие от кортежей, в структуре необходимо именовать каждую часть данных для понимания смысла значений. Добавление этих имён обеспечивает большую гибкость структур по сравнению с кортежами: не нужно полагаться на порядок данных для указания значений экземпляра или доступа к ним.Для определения структуры указывается ключевое слово struct и её название.Название должно описывать значение частей данных, сгруппированных вместе. Далее, в фигурных скобках для каждой новой части данных поочерёдно определяются имя части данных и её тип. Каждая пара имя: тип называется полем. Листинг 5-1 описывает структуру для хранения информации об учётной записи пользователя:Листинг 5-1: Определение структуры UserПосле определения структуры можно создавать её экземпляр, назначая определённое значение каждому полю с соответствующим типом данных. Чтобы создать экземпляр, мы указываем имя структуры, затем добавляем фигурные скобки и включаем в них пары ключ: значение (key: value), где ключами являются имена полей, а значениями являются данные, которые мы хотим сохранить в полях. Нет необходимости чётко следовать порядку объявления полей в описании структуры (но всё-таки желательно для удобства чтения). Другими словами, объявление структуры - это как шаблон нашего типа, в то время как экземпляр структуры использует этот шаблон, заполняя его определёнными данными, для создания значений нашего типа. Например, можно объявить пользователя как в листинге 5-2:Листинг 5-2: Создание экземпляра структуры UserЧтобы получить конкретное значение из структуры, мы используем запись через точку.Например, чтобы получить доступ к адресу электронной почты этого пользователя, мы structUser { active: bool, username: String, email: String, sign_in_count: u64, } fn main() { let user1 = User { email: String::from("someone@example.com"), username: String::from("someusername123"), active: true, sign_in_count: 1, }; } используем user1.email. Если экземпляр является изменяемым, мы можем поменять значение, используя точечную нотацию и присвоение к конкретному полю. В Листинге5-3 показано, как изменить значение в поле email изменяемого экземпляра UserЛистинг 5-3: Изменение значения в поле email экземпляра UserЗаметим, что весь экземпляр структуры должен быть изменяемым; Rust не позволяет помечать изменяемыми отдельные поля. Как и для любого другого выражения, мы можем использовать выражение создания структуры в качестве последнего выражения тела функции для неявного возврата нового экземпляра.На листинге 5-4 функция build_user возвращает экземпляр User с указанным адресом и именем. Поле active получает значение true, а поле sign_in_count получает значение1Листинг 5-4: Функция build_user, которая принимает email и имя пользователя и возвращает экземпляр UserИмеет смысл называть параметры функции теми же именами, что и поля структуры, но необходимость повторять email и username для названий полей и переменных несколько утомительна. Если структура имеет много полей, повторение каждого имени станет ещё более раздражающим. К счастью, есть удобное сокращение!Использование сокращённой инициализации поляТак как имена входных параметров функции и полей структуры являются полностью идентичными в листинге 5-4, возможно использовать синтаксис сокращённойfn main() { let mut user1 = User { email: String::from("someone@example.com"), username: String::from("someusername123"), active: true, sign_in_count: 1, }; user1.email = String::from("anotheremail@example.com"); } fn build_user(email: String, username: String) -> User { User { email: email, username: username, active: true, sign_in_count: 1, } } инициализации поля, чтобы переписать build_user так, чтобы он работал точно также,но не содержал повторений для email и username, как в листинге 5-5.Листинг 5-5: Функция build_user, использующая сокращённую инициализацию поля, когда параметры email и username имеют те же имена, что и поля structЗдесь происходит создание нового экземпляра структуры User, которая имеет поле с именем email. Мы хотим установить поле структуры email значением входного параметра email функции build_user. Так как поле email и входной параметр функции email имеют одинаковое название, можно писать просто email вместо кода email: emailСоздание экземпляра структуры из экземпляра другой структуры спомощью синтаксиса обновления структурыЧасто бывает полезно создать новый экземпляр структуры, который включает большинство значений из другого экземпляра, но некоторые из них изменяет. Это можно сделать с помощью синтаксиса обновления структуры.Сначала в листинге 5-6 показано, как обычно создаётся новый экземпляр User в user2без синтаксиса обновления. Мы задаём новое значение для email, но в остальном используем те же значения из user1, которые были заданы в листинге 5-2.Листинг 5-6: Создание нового экземпляра User с использованием некоторых значений из экземпляра user1Используя синтаксис обновления структуры, можно получить тот же эффект, используя меньше кода как показано в листинге 5-7. Синтаксис указывает, что оставшиеся поля fn build_user(email: String, username: String) -> User { User { email, username, active: true, sign_in_count: 1, } } fn main() { // --snip-- let user2 = User { active: user1.active, username: user1.username, email: String::from("another@example.com"), sign_in_count: user1.sign_in_count, }; } устанавливаются неявно и должны иметь значения из указанного экземпляра.Листинг 5-7: Использование синтаксиса обновления структуры для установки нового значения email дляэкземпляра User, но использование остальных значений из экземпляра user1Код в листинге 5-7 также создаёт экземпляр в user2, который имеет другое значение для email, но с тем же значением для полей username, active и sign_in_count из user1Оператор ..user1 должен стоять последним для указания на получение значений всех оставшихся полей из соответствующих полей в user1, но можно указать значения для любого количества полей в любом порядке, независимо от порядка полей в определении структуры.Заметим, что синтаксис обновления структуры использует = как присваивание. Это связано с перемещением данных, как мы видели в разделе "Способы взаимодействия переменных и данных: перемещение". В этом примере мы больше не можем использовать user1 после создания user2, потому что String в поле username из user1 было перемещено в user2. Если бы мы задали user2 новые значения String для email и username, и при этом использовать только значения active и sign_in_count из user1, то user1 все ещё будет действительным после создания user2. Типы active и sign_in_count являются типами, реализующими типаж Copy, поэтому будет применяться поведение, о котором мы говорили в разделе "Стековые данные:Копирование"Кортежные структуры: структуры без именованных полей длясоздания разных типовRust также поддерживает структуры, похожие на кортежи, которые называютсякортежные структуры. Кортежные структуры обладают дополнительным смыслом,который даёт имя структуры, но при этом не имеют имён, связанных с их полями. Скорее,они просто хранят типы полей. Кортежные структуры полезны, когда вы хотите дать имя всему кортежу и сделать кортеж отличным от других кортежей, и когда именование каждого поля, как в обычной структуре, было бы многословным или избыточным.Чтобы определить кортежную структуру, начните с ключевого слова struct и имени структуры, за которым следуют типы в кортеже. Например, здесь мы определяем и используем две кортежные структуры с именами Color и Point:fn main() { // --snip-- let user2 = User { email: String::from("another@example.com"), ..user1 }; } Обратите внимание, что значения black и origin — это разные типы, потому что они являются экземплярами разных кортежных структур. Каждая определяемая вами структура имеет собственный тип, даже если поля внутри структуры могут иметь одинаковые типы. Например, функция, принимающая параметр типа Color, не может принимать Point в качестве аргумента, даже если оба типа состоят из трёх значений i32. В остальном экземпляры кортежных структур похожи на кортежи в том смысле, что вы можете деструктурировать их на отдельные части и использовать , за которой следует индекс для доступа к отдельному значению.Единично-подобные структуры: структуры без полейТакже можно определять структуры, не имеющие полей! Они называются единично-подобными структурами, поскольку ведут себя аналогично (), единичному типу, о котором мы говорили в разделе "Кортежи". Единично-подобные структуры могут быть полезны, когда требуется реализовать типаж для некоторого типа, но у вас нет данных,которые нужно хранить в самом типе. Мы обсудим типажи в главе 10. Вот пример объявления и создание экземпляра единичной структуры с именем AlwaysEqual:Чтобы определить AlwaysEqual, мы используем ключевое слово struct, желаемое имя,а затем точку с запятой. Нет необходимости в фигурных или круглых скобках! Затем мы можем получить экземпляр AlwaysEqual в переменной subject аналогичным образом:используя имя, которое мы определили, без фигурных и круглых скобок. Представим, что в дальнейшем мы реализуем поведение для этого типа таким образом, что каждый экземпляр AlwaysEqual всегда будет равен каждому экземпляру любого другого типа,возможно, с целью получения ожидаемого результата для тестирования. Для реализации такого поведения нам не нужны никакие данные! В главе 10 вы увидите, как определять черты и реализовывать их для любого типа, включая единично-подобные структуры.Владение данными структурыstructColor(i32, i32, i32); structPoint(i32, i32, i32); fn main() { let black = Color(0, 0, 0); let origin = Point(0, 0, 0); } structAlwaysEqual; fn main() { let subject = AlwaysEqual; } В определении структуры User в листинге 5-1 мы использовали владеющий тип String вместо типа строковой срез &str. Это осознанный выбор, поскольку мы хотим, чтобы каждый экземпляр этой структуры владел всеми своими данными и чтобы эти данные были действительны до тех пор, пока действительна вся структура.Структуры также могут хранить ссылки на данные, принадлежащие кому-то другому,но для этого необходимо использовать возможность Rust время жизни, которую мы обсудим в главе 10. Время жизни гарантирует, что данные, на которые ссылается структура, будут действительны до тех пор, пока существует структура. Допустим,если попытаться сохранить ссылку в структуре без указания времени жизни, как в следующем примере; это не сработает:Имя файла: src/main.rsКомпилятор будет жаловаться на необходимость определения времени жизни ссылок:structUser { active: bool, username: &str, email: &str, sign_in_count: u64, } fn main() { let user1 = User { email: "someone@example.com", username: "someusername123", active: true, sign_in_count: 1, }; } В главе 10 мы обсудим, как исправить эти ошибки, чтобы иметь возможность хранить ссылки в структурах, а пока мы исправим подобные ошибки, используя владеющие типы вроде String вместо ссылок &str$ cargo run Compiling structs v0.1.0 (file:///projects/structs) error[E0106]: missing lifetime specifier --> src/main.rs:3:15 | 3 | username: &str, | ^ expected named lifetime parameter | help: consider introducing a named lifetime parameter | 1 struct User<'a> { 2 | active: bool, 3 username: &'a str, | error[E0106]: missing lifetime specifier --> src/main.rs:4:12 | 4 | email: &str, | ^ expected named lifetime parameter | help: consider introducing a named lifetime parameter | 1 struct User<'a> { 2 | active: bool, 3 | username: &str, 4 email: &'a str, | For more information about this error, try `rustc --explain E0106`. error: could not compile `structs` due to 2 previous errors Пример использования структурЧтобы понять, когда нам может понадобиться использование структур, давайте напишем программу, которая вычисляет площадь прямоугольника. Мы начнём с использования одиночных переменных, а затем будем улучшать программу до использования структур.Давайте создадим новый проект программы при помощи Cargo и назовём его rectangles.Наша программа будет получать на вход длину и ширину прямоугольника в пикселях и затем рассчитывать площадь прямоугольника. Листинг 5-8 показывает один из коротких вариантов кода, который позволит нам сделать именно то, что надо, в файле проектаsrc/main.rs.Файл: src/main.rsЛистинг 5-8: вычисление площади прямоугольника, заданного отдельными переменными ширины ивысотыТеперь запустим программу, используя cargo run:Этот код успешно вычисляет площадь прямоугольника, вызывая функцию area скаждым измерением, но мы можем улучшить его ясность и читабельность.Проблема данного метода очевидна из сигнатуры area:Функция area должна вычислять площадь одного прямоугольника, но функция, которую мы написали, имеет два параметра, и нигде в нашей программе не ясно, что эти параметры взаимосвязаны. Было бы более читабельным и управляемым сгруппировать fn main() { let width1 = 30; let height1 = 50; println!( "The area of the rectangle is {} square pixels.", area(width1, height1) ); } fn area(width: u32, height: u32) -> u32 { width * height } $ cargo run Compiling rectangles v0.1.0 (file:///projects/rectangles) Finished dev [unoptimized + debuginfo] target(s) in 0.42s Running `target/debug/rectangles` The area of the rectangle is 1500 square pixels. fn area(width: u32, height: u32) -> u32 { ширину и высоту вместе. В разделе «Кортежи» главы 3 мы уже обсуждали один из способов сделать это — использовать кортежи.Рефакторинг при помощи кортежейЛистинг 5-9 — это другая версия программы, использующая кортежи.Файл: src/main.rsЛистинг 5-9: определение ширины и высоты прямоугольника с помощью кортежаС одной стороны, эта программа лучше. Кортежи позволяют добавить немного структуры, и теперь мы передаём только один аргумент. Но с другой стороны, эта версия менее понятна: кортежи не называют свои элементы, поэтому нам приходится индексировать части кортежа, что делает наше вычисление менее очевидным.Если мы перепутаем местами ширину с высотой при расчёте площади, то это не имеет значения. Но если мы хотим нарисовать прямоугольник на экране, то это уже будет важно! Мы должны помнить, что ширина width находится в кортеже с индексом 0, а высота height — с индексом 1. Если кто-то другой поработал бы с кодом, ему бы пришлось разобраться в этом и также помнить про порядок. Легко забыть и перепутать эти значения — и это вызовет ошибки, потому что данный код не передаёт наши намерения.Рефакторинг при помощи структур: добавим больше смыслаМы используем структуры, чтобы добавить смысл данным при помощи назначения им осмысленных имён . Мы можем переделать используемый кортеж в структуру с единым именем для сущности и частными названиями её частей, как показано в листинге 5-10.Файл: src/main.rs fn main() { let rect1 = (30, 50); println!( "The area of the rectangle is {} square pixels.", area(rect1) ); } fn area(dimensions: (u32, u32)) -> u32 { dimensions.0 * dimensions.1} Листинг 5-10: определение структуры RectangleЗдесь мы определили структуру и дали ей имя Rectangle. Внутри фигурных скобок определили поля как width и height, оба — типа u32. Затем в main создали конкретный экземпляр Rectangle с шириной в 30 и высотой в 50 единиц.Наша функция area теперь определена с одним параметром, названным rectangle, чей тип является неизменяемым заимствованием структуры Rectangle. Как упоминалось в главе 4, необходимо заимствовать структуру, а не передавать её во владение. Таким образом функция main сохраняет rect1 в собственности и может использовать еёдальше. По этой причине мы и используем & в сигнатуре и в месте вызова функции.Функция area получает доступ к полям width и height экземпляра Rectangle (обратите внимание, что доступ к полям заимствованного экземпляра структуры не приводит к перемещению значений полей, поэтому вы часто видите заимствования структур). Наша сигнатура функции для area теперь говорит именно то, что мы имеем в виду: вычислить площадь Rectangle, используя его поля width и height. Это означает, что ширина и высота связаны друг с другом, и даёт описательные имена значениям, а не использует значения индекса кортежа 0 и 1. Это торжество ясности.Добавление полезной функциональности при помощи выводимых1 ... 6 7 8 9 10 11 12 13 ... 62

help: use `impl Fn(i32) -> i32` as the return type, as all return paths are of type `[closure@src/lib.rs:2:5: 2:14]`, which implements `Fn(i32) -> i32` | 1 | fn returns_closure() -> impl Fn(i32) -> i32 { |

Исправимые ошибки с Result
Многие ошибки являются не настолько критичными, чтобы останавливать выполнение программы. Иногда, когда в функции происходит сбой, необходима просто правильная интерпретация и обработка ошибки. К примеру, при попытке открыть файл может произойти ошибка из-за отсутствия файла. Вы, возможно, захотите исправить ситуацию и создать новый файл вместо остановки программы.
Вспомните раздел ["Обработка потенциального сбоя с помощью типа
Result
"] главы 2:
мы использовали там перечисление
Result
, имеющее два варианта,
Ok и
Err для обработки сбоев. Само перечисление определено следующим образом:
Типы
T
и
E
являются параметрами обобщённого типа: мы обсудим обобщённые типы более подробно в Главе 10. Все что вам нужно знать прямо сейчас - это то, что
T
представляет тип значения, которое будет возвращено в случае успеха внутри варианта
Ok
, а
E
представляет тип ошибки, которая будет возвращена при сбое внутри варианта
Err
. Так как тип
Result имеет эти обобщённые параметры (generic type parameters), мы можем использовать тип
Result и функции, которые определены для него, в разных ситуациях, когда тип успешного значение и значения ошибки, которые мы хотим вернуть, отличаются.
Давайте вызовем функцию, которая возвращает значение
Result
, потому что может потерпеть неудачу. В листинге 9-3 мы пытаемся открыть файл.
Файл: src/main.rs
Листинг 9-3: Открытие файла
File::open возвращает значения типа
Result
. Универсальный тип
T
в реализации
File::open соответствует типу успешно полученного значения, std::fs::File
, а именно дескриптору файла. Тип
E
, используемый для значения в случае возникновения ошибки, - std::io::Error
. Такой возвращаемый тип означает, что вызов
File::open может быть успешным и вернуть дескриптор файла, из которого мы можем читать или в который можем писать. Также вызов функции может завершиться неудачей: например, файл может не существовать, или у нас может не быть разрешения enum
Result
{
Ok
(T),
Err
(E),
} use std::fs::File; fn main
() { let greeting_file_result = File::open(
"hello.txt"
);
}

на доступ к файлу. Функция
File::open должна иметь способ сообщить нам об успехе или неудаче и в то же время дать нам либо дескриптор файла, либо информацию об ошибке. Эту возможность как раз и предоставляет перечисление
Result
В случае успеха
File::open значением переменной greeting_file_result будет экземпляр
Ok
, содержащий дескриптор файла. В случае неудачи значение в переменной greeting_file_result будет экземпляром
Err
, содержащим дополнительную информацию о том, какая именно ошибка произошла.
Необходимо дописать в код листинга 9-3 выполнение разных действий в зависимости от значения, которое вернёт вызов
File::open
. Листинг 9-4 показывает один из способов обработки
Result
- пользуясь базовым инструментом языка, таким как выражение match
, рассмотренным в Главе 6.
Файл: src/main.rs
Листинг 9-4: Использование выражения
match
для обработки возвращаемых вариантов типа
Result
Обратите внимание, что также как перечисление
Option
, перечисление
Result и его варианты, входят в область видимости благодаря авто-импорту (prelude), поэтому не нужно указывать
Result::
перед использованием вариантов
Ok и
Err в ветках выражения match
Если результатом будет
Ok
, этот код вернёт значение file из варианта
Ok
, а мы затем присвоим это значение файлового дескриптора переменной greeting_file
. После match мы можем использовать дескриптор файла для чтения или записи.
Другая ветвь match обрабатывает случай, где мы получаем значение
Err после вызова
File::open
. В этом примере мы решили вызвать макрос panic!
. Если в нашей текущей директории нет файла с именем hello.txt и мы выполним этот код, то мы увидим следующее сообщение от макроса panic!
:
use std::fs::File; fn main
() { let greeting_file_result = File::open(
"hello.txt"
); let greeting_file = match greeting_file_result {
Ok
(file) => file,
Err
(error) => panic!
(
"Problem opening the file: {:?}"
, error),
};
}

Как обычно, данное сообщение точно говорит, что пошло не так.
Обработка различных ошибок с помощью match
Код в листинге 9-4 будет вызывать panic!
независимо от того, почему вызов
File::open не удался. Однако мы хотим предпринять различные действия для разных причин сбоя.
Если открытие
File::open не удалось из-за отсутствия файла, мы хотим создать файл и вернуть его дескриптор. Если вызов
File::open не удался по любой другой причине - например, потому что у нас не было прав на открытие файла, то все равно мы хотим вызвать panic!
как у нас сделано в листинге 9-4. Для этого мы добавляем выражение внутреннего match
, показанное в листинге 9-5.
Файл: src/main.rs
Листинг 9-5: Обработка различных ошибок разными способами
Типом значения возвращаемого функцией
File::open внутри
Err варианта является io::Error
, структура из стандартной библиотеки. Данная структура имеет метод kind
,
который можно вызвать для получения значения io::ErrorKind
. Перечисление io::ErrorKind из стандартной библиотеки имеет варианты, представляющие различные типы ошибок, которые могут появиться при выполнении операций в io
. Вариант,
$
cargo run
Compiling error-handling v0.1.0 (file:///projects/error-handling)
Finished dev [unoptimized + debuginfo] target(s) in 0.73s
Running `target/debug/error-handling` thread 'main' panicked at 'Problem opening the file: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:8:23 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace use std::fs::File; use std::io::ErrorKind; fn main
() { let greeting_file_result = File::open(
"hello.txt"
); let greeting_file = match greeting_file_result {
Ok
(file) => file,
Err
(error) => match error.kind() {
ErrorKind::NotFound => match
File::create(
"hello.txt"
) {
Ok
(fc) => fc,
Err
(e) => panic!
(
"Problem creating the file: {:?}"
, e),
}, other_error => { panic!
(
"Problem opening the file: {:?}"
, other_error);
}
},
};
}

который мы хотим использовать, это
ErrorKind::NotFound
, который даёт информацию, о том, что файл который мы пытаемся открыть ещё не существует. Итак, во второй строке мы вызываем сопоставление шаблона с переменной greeting_file_result и попадаем в ветку с обработкой ошибки, но также у нас есть внутренняя проверка для сопоставления error.kind()
ошибки.
Условие, которое мы хотим проверить во внутреннем match
, заключается в том,
является ли значение, возвращаемое error.kind()
, вариантом
NotFound перечисления
ErrorKind
. Если это так, мы пытаемся создать файл с помощью функции
File::create
Однако, поскольку вызов
File::create тоже может завершиться ошибкой, нам нужна обработка ещё одной ошибки, теперь уже во внутреннем выражении match
. Заметьте:
если файл не может быть создан, выводится другое, специализированное сообщение об ошибке. Вторая же ветка внешнего match
(который обрабатывает вызов error.kind()
),
остаётся той же самой - в итоге программа паникует при любой ошибке, кроме ошибки отсутствия файла.
Альтернативы использованию match с Result
Как много match
! Выражение match является очень полезным, но в то же время довольно примитивным. В главе 13 вы узнаете о замыканиях (closures), которые используются во многих методах типа
Result
. Эти методы помогают быть более лаконичным, чем использование match при работе со значениями
ResultE>
в вашем коде.
Например, вот другой способ написать ту же логику, что показана в Листинге 9-5, но с использованием замыканий и метода unwrap_or_else
:
Хотя этот код ведёт себя так же, как и код из листинга 9-5, он не содержит никаких выражений match и его легче читать. После прочтения главы 13 и поищите метод unwrap_or_else в документации по стандартной библиотеке. Множество других use std::fs::File; use std::io::ErrorKind; fn main
() { let greeting_file = File::open(
"hello.txt"
).unwrap_or_else(|error| { if error.kind() == ErrorKind::NotFound {
File::create(
"hello.txt"
).unwrap_or_else(|error| { panic!
(
"Problem creating the file: {:?}"
, error);
})
} else
{ panic!
(
"Problem opening the file: {:?}"
, error);
}
});
}

подобных методов могут очистить огромные вложенные выражения match, когда вы имеете дело с ошибками.
Лаконичные способы обработки ошибок - unwrap и expect
Использование match работает достаточно хорошо, но может быть довольно многословным и не всегда хорошо передаёт смысл. Тип
Result
имеет множество вспомогательных методов для выполнения различных, более специфических задач.
Метод unwrap
- это метод быстрого доступа к значениям, реализованный так же, как и выражение match
, которое мы написали в Листинге 9-4. Если значение
Result является вариантом
Ok
, unwrap возвращает значение внутри
Ok
. Если
Result
- вариант
Err
, то unwrap вызовет для нас макрос panic!
. Вот пример unwrap в действии:
Файл: src/main.rs
Если мы запустим этот код при отсутствии файла hello.txt, то увидим сообщение об ошибке из вызова panic!
метода unwrap
:
Другой метод, похожий на unwrap
, это expect
, позволяющий указать сообщение об ошибке для макроса panic!
. Использование expect вместо unwrap с предоставлением хорошего сообщения об ошибке выражает ваше намерение и делает более простым отслеживание источника паники. Синтаксис метода expect выглядит так:
Файл: src/main.rs expect используется так же как и unwrap
: либо возвращается дескриптор файла либо вызывается макрос panic!
Наше сообщение об ошибке в expect будет передано в panic!
и заменит стандартное use std::fs::File; fn main
() { let greeting_file = File::open(
"hello.txt"
).unwrap();
} thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:4:49 use std::fs::File; fn main
() { let greeting_file = File::open(
"hello.txt"
)
.expect(
"hello.txt should be included in this project"
);
}

используемое сообщение.
Вот как это выглядит:
В рабочем коде, большинство выбирает expect в угоду unwrap и добавляет описание,
почему операция должна закончиться успешно. Но даже если предположение оказалось неверным, информации для отладки будет больше.
Проброс ошибок
Когда вы пишете функцию, реализация которой вызывает что-то, что может завершиться ошибкой, вместо обработки ошибки в этой функции, вы можете вернуть ошибку в вызывающий код, чтобы он мог решить, что с ней делать. Такой приём известен как
распространение ошибки (propagating the error). Благодаря нему мы даём больше контроля вызывающему коду, где может быть больше информации или логики, которая диктует, как ошибка должна обрабатываться, чем было бы в месте появления этой ошибки.
Например, код программы 9-6 читает имя пользователя из файла. Если файл не существует или не может быть прочтён, то функция возвращает ошибку в код, который вызвал данную функцию.
Файл: src/main.rs
Листинг 9-6: Функция, которая возвращает ошибки в вызывающий код, используя оператор
match thread 'main' panicked at 'hello.txt should be included in this project: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:5:10 use std::fs::File; use std::io::{
self
, Read}; fn read_username_from_file
() ->
Result
<
String
, io::Error> { let username_file_result = File::open(
"hello.txt"
); let mut username_file = match username_file_result {
Ok
(file) => file,
Err
(e) => return
Err
(e),
}; let mut username =
String
::new(); match username_file.read_to_string(&
mut username) {
Ok
(_) =>
Ok
(username),
Err
(e) =>
Err
(e),
}
}

Эта функция может быть написана гораздо более коротким способом, но мы начнём с того, что многое сделаем вручную, чтобы изучить обработку ошибок; а в конце покажем более короткий способ. Давайте сначала рассмотрим тип возвращаемого значения:
Result
. Здесь есть возвращаемое значение функции типа
ResultE>
где шаблонный параметр
T
был заполнен конкретным типом
String и шаблонный параметр
E
был заполнен конкретным типом io::Error
Если эта функция выполнится без проблем, то код, вызывающий эту функцию, получит значение
Ok
, содержащее
String
- имя пользователя, которое эта функция прочитала из файла. Если функция столкнётся с какими-либо проблемами, вызывающий код получит значение
Err
, содержащее экземпляр io::Error
, который включает дополнительную информацию о том, какие проблемы возникли. Мы выбрали io::Error в качестве возвращаемого типа этой функции, потому что это тип значения ошибки,
возвращаемого из обеих операций, которые мы вызываем в теле этой функции и которые могут завершиться неудачей: функция
File::open и метод read_to_string
Тело функции начинается с вызова
File::open
. Затем мы обрабатываем значение
Result с помощью match
, аналогично match из листинга 9-4. Если
File::open завершается успешно, то дескриптор файла в переменной образца file становится значением в изменяемой переменной username_file и функция продолжит свою работу.
В случае
Err
, вместо вызова panic!
, мы используем ключевое слово return для досрочного возврата из функции и передаём значение ошибки из
File::open
, которое теперь находится в переменной образца e
, обратно в вызывающий код как значение ошибки этой функции.
Таким образом, если у нас есть файловый дескриптор в username_file
, функция создаёт новую
String в переменной username и вызывает метод read_to_string для файлового дескриптора в username_file
, чтобы прочитать содержимое файла в username
. Метод read_to_string также возвращает
Result
, потому что он может потерпеть неудачу, даже если
File::open завершился успешно. Поэтому нам нужен ещё один match для обработки этого
Result
: если read_to_string завершится успешно, то наша функция сработала, и мы возвращаем имя пользователя из файла, которое теперь находится в username
, обёрнутое в
Ok
. Если read_to_string потерпит неудачу, мы возвращаем значение ошибки таким же образом, как мы возвращали значение ошибки в match
,
который обрабатывал возвращаемое значение
File::open
. Однако нам не нужно явно указывать return
, потому что это последнее выражение в функции.
Затем код, вызывающий этот, будет обрабатывать получение либо значения
Ok
,
содержащего имя пользователя, либо значения
Err
, содержащего io::Error
Вызывающий код должен решить, что делать с этими значениями. Если вызывающий код получает значение
Err
, он может вызвать panic!
и завершить работу программы,
использовать имя пользователя по умолчанию или найти имя пользователя, например,
не в файле. У нас недостаточно информации о том, что на самом деле пытается сделать вызывающий код, поэтому мы распространяем всю информацию об успехах или ошибках вверх, чтобы она могла обрабатываться соответствующим образом.

Эта схема передачи ошибок настолько распространена в Rust, что Rust предоставляет оператор вопросительного знака
?
, чтобы облегчить эту задачу.
Сокращение для проброса ошибок: оператор ?
В листинге 9-7 показана реализация read_username_from_file
, которая имеет ту же функциональность, что и в листинге 9-6, но в этой реализации используется оператор
?
Файл: src/main.rs
Листинг 9-7: Функция, возвращающая ошибки в вызывающий код с помощью оператора
?
Выражение
?
, расположенное после
Result
, работает почти так же, как и те выражения match
, которые мы использовали для обработки значений
Result в листинге 9-6. Если в качестве значения
Result будет
Ok
, то значение внутри
Ok будет возвращено из этого выражения, и программа продолжит работу. Если же значение представляет собой
Err
,
то
Err будет возвращено из всей функции, как если бы мы использовали ключевое слово return
, так что значение ошибки будет передано в вызывающий код.
Существует разница между тем, что делает выражение match из листинга 9-6 и тем, что делает оператор
?
: значения ошибок, для которых вызван оператор
?
, проходят через функцию from
, определённую в трейте
From стандартной библиотеки, которая используется для преобразования значений из одного типа в другой. Когда оператор
?
вызывает функцию from
, полученный тип ошибки преобразуется в тип ошибки,
определённый в возвращаемом типе текущей функции. Это полезно, когда функция возвращает только один тип ошибки, для описания всех возможных вариантов сбоев,
даже если её отдельные компоненты могут выходить из строя по разным причинам.
Например, мы могли бы изменить функцию read_username_from_file в листинге 9-7,
чтобы возвращать пользовательский тип ошибки с именем
OurError
, который мы определим. Если мы также определим impl From<:error> for OurError для создания экземпляра
OurError из io::Error
, то оператор
?
, вызываемый в теле read_username_from_file
, вызовет from и преобразует типы ошибок без необходимости добавления дополнительного кода в функцию.
use std::fs::File; use std::io; use std::io::Read; fn read_username_from_file
() ->
Result
<
String
, io::Error> { let mut username_file = File::open(
"hello.txt"
)?; let mut username =
String
::new(); username_file.read_to_string(&
mut username)?;
Ok
(username)
}

В случае листинга 9-7 оператор
?
в конце вызова
File::open вернёт значение внутри
Ok в переменную username_file
. Если произойдёт ошибка, оператор
?
выполнит ранний возврат значения
Err вызывающему коду. То же самое относится к оператору
?
в конце вызова read_to_string
Оператор
?
позволяет избавиться от большого количества шаблонного кода и упростить реализацию этой функции. Мы могли бы даже ещё больше сократить этот код,
если бы использовали цепочку вызовов методов сразу после
?
, как показано в листинге
9-8.
Файл: src/main.rs

1 ... 16 17 18 19 20 21 22 23 ... 62

Листинг 9-8: Цепочка вызовов методов после оператора
?
Мы перенесли создание новой
String в username в начало функции; эта часть не изменилась. Вместо создания переменной username_file мы соединили вызов read_to_string непосредственно с результатом
File::open("hello.txt")?
. У нас по- прежнему есть
?
в конце вызова read_to_string
, и мы по-прежнему возвращаем значение
Ok
, содержащее username
, когда и
File::open и read_to_string завершаются успешно, а не возвращают ошибки. Функциональность снова такая же, как в Листинге 9-6
и Листинге 9-7; это просто другой, более эргономичный способ её написания.
Продолжая рассматривать разные способы записи данной функции, листинг 9-9
демонстрирует способ сделать её ещё короче.
Файл: src/main.rs
Листинг 9-9: Использование
fs::read_to_string
вместо открытия и последующего чтения файла
use std::fs::File; use std::io; use std::io::Read; fn read_username_from_file
() ->
Result
<
String
, io::Error> { let mut username =
String
::new();
File::open(
"hello.txt"
)?.read_to_string(&
mut username)?;
Ok
(username)
} use std::fs; use std::io; fn read_username_from_file
() ->
Result
<
String
, io::Error> { fs::read_to_string(
"hello.txt"
)
}

Чтение файла в строку довольно распространённая операция, так что стандартная библиотека предоставляет удобную функцию fs::read_to_string
, которая открывает файл, создаёт новую
String
, читает содержимое файла, размещает его в
String и
возвращает её. Конечно, использование функции fs::read_to_string не даёт возможности объяснить обработку всех ошибок, поэтому мы сначала изучили длинный способ.
Где можно использовать оператор ?
?
может использоваться только в функциях, тип возвращаемого значения которых совместим со значением
?
используется на. Это потому, что
?
оператор определён для выполнения раннего возврата значения из функции таким же образом, как и выражение match
, которое мы определили в листинге 9-6. В листинге 9-6 match использовало значение
Result
, а ответвление с ранним возвратом вернуло значение
Err(e)
. Тип возвращаемого значения функции должен быть
Result
, чтобы он был совместим с этим return
В листинге 9-10 давайте посмотрим на ошибку, которую мы получим, если воспользуемся
?
оператор в main функции с типом возвращаемого значения, несовместимым с типом используемого нами значения
?
на:
Файл : src/main.rs
Листинг 9-10: Попытка использовать
?
в
main
функции, которая возвращает
()
, не будет
компилироваться
Этот код открывает файл, что может привести к сбою.
?
оператор следует за значением
Result
, возвращаемым
File::open
, но эта main функция имеет возвращаемый тип
()
, а не
Result
. Когда мы компилируем этот код, мы получаем следующее сообщение об ошибке:
use std::fs::File; fn main
() { let greeting_file = File::open(
"hello.txt"
)?;
}

Эта ошибка указывает на то, что оператор
?
разрешено использовать только в функции,
которая возвращает
Result
,
Option или другой тип, реализующий
FromResidual
Для исправления ошибки есть два варианта. Первый - изменить возвращаемый тип вашей функции так, чтобы он был совместим со значением, для которого вы используете оператор
?
, если у вас нет ограничений, препятствующих этому. Другой способ - использовать match или один из методов
Result
для обработки
Result
любым подходящим способом.
Эта ошибка указывает на то, что оператор
?
разрешено использовать только в функции,
которая возвращает
Result
,
Option или другой тип, который реализует
FromResidual
Чтобы исправить ошибку, есть два варианта. Первый - изменить тип возвращаемый из функции, чтобы он был совместим со значением, для которого вы используете оператор
?
, если у вас нет ограничений, препятствующих этому. Второй заключается в использовании match или одного из методов
Result
для обработки
Result
любым подходящим способом.
Listing 9-11: Using the
?
operator on an
Option
value
Эта функция возвращает
Option
, потому что возможно, что там есть символ, но также возможно, что его нет. Этот код принимает аргумент среза text строки и вызывает для него метод lines
, который возвращает итератор для строк в строке.
Поскольку эта функция хочет проверить первую строку, она вызывает next у итератора,
чтобы получить первое значение от итератора. Если text является пустой строкой, этот вызов next вернёт
None
, и в этом случае мы используем
?
чтобы остановить и вернуть
$
cargo run
Compiling error-handling v0.1.0 (file:///projects/error-handling) error[E0277]: the `?` operator can only be used in a function that returns
`Result` or `Option` (or another type that implements `FromResidual`)
-->
src/main.rs:4:48
|
3 | / fn main() {
4 | | let greeting_file = File::open("hello.txt")?;
| | ^ cannot use the `?` operator in a function that returns `()`
5 | | }
| |_- this function should return `Result` or `Option` to accept `?`
|
= help: the trait `FromResidual>` is not implemented for `()`
For more information about this error, try `rustc --explain E0277`. error: could not compile `error-handling` due to previous error fn last_char_of_first_line
(text: &
str
) ->
Option
<
char
> { text.lines().next()?.chars().last()
}

None из last_char_of_first_line
. Если text не является пустой строкой, next вернёт значение
Some
, содержащее фрагмент строки первой строки в text
Символ
?
извлекает фрагмент строки, и мы можем вызвать chars для этого фрагмента строки. чтобы получить итератор символов. Нас интересует последний символ в первой строке, поэтому мы вызываем last
, чтобы вернуть последний элемент в итераторе.
Вернётся
Option
, потому что возможно, что первая строка пустая - например, если text начинается с пустой строки, но имеет символы в других строках, как в "\nhi"
. Однако,
если в первой строке есть последний символ, он будет возвращён в варианте
Some
Оператор
?
в середине даёт нам лаконичный способ выразить эту логику, позволяя реализовать функцию в одной строке. Если бы мы не могли использовать оператор
?
в
Option
, нам пришлось бы пришлось бы реализовать эту логику, используя больше вызовов методов или выражение match
Обратите внимание, что вы можете использовать
?
оператор
Result в функции,
которая возвращает
Result
, и вы можете использовать оператор
?
оператор на
Option в функции, которая возвращает
Option
, но вы не можете смешивать и сопоставлять.
?
оператор не будет автоматически преобразовывать
Result в
Option или наоборот; в этих случаях вы можете использовать такие методы, как метод ok для
Result или метод ok_or для
Option
, чтобы выполнить преобразование явно.
Обратите внимание, что вы можете использовать оператор
?
на
Result в функции,
которая возвращает
Result
, и вы можете использовать оператор
?
на
Option в
функции, которая возвращает
Option
, но вы не можете смешивать и сочетать их.
Оператор
?
не будет автоматически преобразовывать
Result в
Option или наоборот; в этих случаях, вы можете использовать такие методы, как ok из
Result или ok_or из
Option для явного преобразования.
К счастью, main также может возвращать
Result<(), E>
. В листинге 9-12 используется код из листинга 9-10, но мы изменили возвращаемый тип main на
Result<(), BoxError>>
и добавили возвращаемое значение
Ok(())
в конец. Теперь этот код будет скомпилирован:
Листинг 9-12: Замена
main
на return
Result<(), E>
позволяет использовать оператор
?
оператор над
значениями
Result
Тип
Box
является трейт-объектом, о котором мы поговорим в разделе "Использование трейт-объектов, допускающих значения разных типов"
в главе 17. Пока use std::error::Error; use std::fs::File; fn main
() ->
Result
<(),
Box
<
dyn
Error>> { let greeting_file = File::open(
"hello.txt"
)?;
Ok
(())
}

что вы можете считать, что
Box
означает "любой вид ошибки".
Использование
?
для значения
Result в функции main с типом ошибки
Box
разрешено, так как позволяет вернуть любое значение
Err раньше времени. Даже если тело этой функции main будет возвращать только ошибки типа std::io::Error
, указав
Box
, эта сигнатура останется корректной, даже если в тело main будет добавлен код, возвращающий другие ошибки.
Когда main функция возвращает
Result<(), E>
, исполняемый файл завершится со значением
0
, если main вернёт
Ok(())
, и выйдет с ненулевым значением, если main вернёт значение
Err
. Исполняемые файлы, написанные на C, при выходе возвращают целые числа: успешно завершённые программы возвращают целое число
0
, а программы с ошибкой возвращают целое число, отличное от
0
. Rust также возвращает целые числа из исполняемых файлов, чтобы быть совместимым с этим соглашением.
Функция main может возвращать любые типы, реализующие трейт std::process::Termination
, в которых имеется функция report
, возвращающая
ExitCode
. Обратитесь к документации стандартной библиотеки за дополнительной информацией о порядке реализации трейта
Termination для ваших собственных типов.
Теперь, когда мы обсудили детали вызова panic!
или возврата
Result
, давайте вернёмся к тому, как решить, какой из случаев подходит для какой ситуации.

panic!
или не panic!
Итак, как принимается решение о том, когда следует вызывать panic!
, а когда вернуть
Result
? При панике код не имеет возможности восстановить своё выполнение. Можно было бы вызывать panic!
для любой ошибочной ситуации, независимо от того, имеется ли способ восстановления или нет, но с другой стороны, вы принимаете решение от имени вызывающего вас кода, что ситуация необратима. Когда вы возвращаете значение
Result
, вы делегируете принятие решения вызывающему коду. Вызывающий код может попытаться выполнить восстановление способом, который подходит в данной ситуации, или же он может решить, что из ошибки в
Err нельзя восстановиться и вызовет panic!
, превратив вашу исправимую ошибку в неисправимую. Поэтому возвращение
Result является хорошим выбором по умолчанию для функции, которая может дать сбой.
В таких ситуация как примеры, прототипы и тесты, более уместно писать код, который паникует вместо возвращения
Result
. Давайте рассмотрим почему, а затем мы обсудим ситуации, в которых компилятор не может доказать, что ошибка невозможна, но вы, как человек, можете это сделать. Глава будет заканчиваться некоторыми общими руководящими принципами о том, как решить, стоит ли паниковать в коде библиотеки.
Примеры, прототипирование и тесты
Когда вы пишете пример, иллюстрирующий некоторую концепцию, наличие хорошего кода обработки ошибок может сделать пример менее понятным. Понятно, что в примерах вызов метода unwrap
, который может привести к панике, является лишь обозначением способа обработки ошибок в приложении, который может отличаться в зависимости от того, что делает остальная часть кода.
Точно так же методы unwrap и expect являются очень удобными при создании прототипа, прежде чем вы будете готовы решить, как обрабатывать ошибки. Они оставляют чёткие маркеры в коде до момента, когда вы будете готовы сделать программу более надёжной.
Если в тесте происходит сбой при вызове метода, то вы бы хотели, чтобы весь тест не прошёл, даже если этот метод не является тестируемой функциональностью. Поскольку вызов panic!
это способ, которым тест помечается как провалившийся, использование unwrap или expect
- именно то, что нужно.
Случаи, в которых у вас больше информации, чем у компилятора
Также было бы целесообразно вызывать unwrap или expect когда у вас есть какая-то другая логика, которая гарантирует, что
Result будет иметь значение
Ok
, но вашу логику не понимает компилятор. У вас по-прежнему будет значение
Result которое

нужно обработать: любая операция, которую вы вызываете, все ещё имеет возможность неудачи в целом, хотя это логически невозможно в вашей конкретной ситуации. Если,
проверяя код вручную, вы можете убедиться, что никогда не будет вариант с
Err
, то вполне допустимо вызывать unwrap
, а ещё лучше задокументировать причину, по которой, по вашему мнению, у вас никогда не будет варианта
Err в тексте expect
. Вот пример:
Мы создаём экземпляр
IpAddr
, анализируя жёстко закодированную строку. Можно увидеть, что
127.0.0.1
является действительным IP-адресом, поэтому здесь допустимо использование expect
. Однако наличие жёстко закодированной допустимой строки не меняет тип возвращаемого значения метода parse
: мы все ещё получаем значение
Result и компилятор все также заставляет нас обращаться с
Result так, будто возможен вариант
Err
, потому что компилятор недостаточно умён, чтобы увидеть, что эта строка всегда действительный IP-адрес. Если строка IP-адреса пришла от пользователя, то она не является жёстко запрограммированной в программе и, следовательно, может
привести к ошибке, мы определённо хотели бы обработать
Result более надёжным способом. Упоминание предположения о том, что этот IP-адрес жёстко закодирован,
побудит нас изменить expect для лучшей обработки ошибок, если в будущем нам потребуется вместо этого получить IP-адрес из какого-либо другого источника.
Руководство по обработке ошибок
Желательно, чтобы код паниковал, если он может оказаться в некорректном состоянии. В
этом контексте некорректное состояние это когда некоторое допущение, гарантия,
контракт или инвариант были нарушены. Например, когда недопустимые,
противоречивые или пропущенные значения передаются в ваш код - плюс один или несколько пунктов из следующего перечисленного в списке:
Не корректное состояние — это что-то неожиданное, отличается от того, что может происходить время от времени, например, когда пользователь вводит данные в неправильном формате.
Ваш код после этой точки должен полагаться на то, что он не находится в не корректном состоянии, вместо проверок наличия проблемы на каждом этапе.
Нет хорошего способа закодировать данную информацию в типах, которые вы используете. Мы рассмотрим пример того, что мы имеем в виду в разделе
“Кодирование состояний и поведения на основе типов”
главы 17.
Если кто-то вызывает ваш код и передаёт значения, которые не имеют смысла, лучше всего вернуть ошибку, если вы это можете, чтобы пользователь библиотеки мог решить,
use std::net::IpAddr; let home: IpAddr =
"127.0.0.1"
.parse()
.expect(
"Hardcoded IP address should be valid"
);

Смотрите также файлы

Выполнение практических заданий по дисциплине административное право.docx

Лабораторная работа 1 Кобеидзе Николай Пример П1.docx

Рабочая программа по английскому языку.docx

Выбрать слово, в котором согласная буква s читается не так, как в остальных предложенных словах.docx

Задача 3 Общин положения.docx

Файл: Язык программирования Rust.pdf

Смотрите также файлы

Информация

Списки файлов

Дополнительно