Современная разработка на JavaScript часто сталкивается с задачами асинхронной работы и обработки ошибок. Как правило, для этих целей используются конструкции try-catch и async-await. Однако они могут утяжелять код и усложнять его восприятие. Чтобы решить эту проблему, был предложен новый оператор безопасного присваивания ?=, который значительно упрощает обработку ошибок и улучшает читаемость кода. В этой статье мы рассмотрим, как работает этот оператор, его особенности и преимущества для разработчиков.
Основные особенности оператора ?=
1. Простая обработка ошибок
Одним из главных преимуществ оператора ?= является возможность удобного и лаконичного контроля ошибок. Вместо того чтобы оборачивать каждый потенциально «опасный» код в блоки try-catch, вы можете использовать оператор безопасного присваивания, который возвращает результат в формате [error, result]. Если ошибка отсутствует, возвращается [null, result]. В противном случае результатом будет [error, null].
Пример:
const [error, data] ?= await fetchData();
if (error) {
console.log("Произошла ошибка:", error);
} else {
console.log("Данные:", data);
}2. Поддержка асинхронных функций и обещаний (Promises)
Оператор ?= работает с обещаниями и асинхронными функциями, что делает его отличным инструментом для управления ошибками в асинхронных процессах. Это особенно полезно в сценариях взаимодействия с API, чтения файлов или любых других операций, которые могут завершиться неудачно.
Пример:
async function getData() {
const [fetchError, response] ?= await fetch("https://api.example.com/data");
if (fetchError) {
handleFetchError(fetchError);
return;
}
const [jsonError, data] ?= await response.json();
if (jsonError) {
handleJsonError(jsonError);
return;
}
return data;
}3. Улучшение читаемости кода
Оператор ?= снижает вложенность кода, убирает избыточные блоки try-catch и делает обработку ошибок более явной и интуитивной. Это способствует лучшей поддержке кода и снижает вероятность упущения критических ошибок.
Пример сравнения:
// Традиционный подход
try {
const response = await fetch("https://api.example.com/data");
const json = await response.json();
const data = parseData(json);
} catch (error) {
handleError(error);
}
// С использованием ?=
const [fetchError, response] ?= await fetch("https://api.example.com/data");
if (fetchError) {
handleFetchError(fetchError);
return;
}4. Унифицированный подход
Оператор совместим с любыми объектами, которые реализуют метод Symbol.result. Это позволяет использовать единый подход для обработки результатов и ошибок независимо от типа данных или API. Такой метод добавляет гибкости в управлении сложными структурами данных и взаимодействиями с различными сервисами.
Пример:
const obj = {
[Symbol.result]() {
return [new Error("Ошибка"), null];
},
};
const [error, result] ?= obj;
if (error) {
console.log("Ошибка:", error);
}Что такое Symbol.result?
Symbol.result — это метод, который можно определить в объектах или функциях для того, чтобы управлять тем, как они возвращают свои результаты в контексте оператора безопасного присваивания. Когда объект или функция сталкиваются с вызовом через оператор ?=, метод Symbol.result автоматически вызывает обработку возвращаемого значения, преобразуя его в удобный кортеж из ошибки и результата: [error, result].
Рассмотрим пример. Допустим, у нас есть объект, который реализует Symbol.result для того, чтобы обрабатывать собственные ошибки:
const obj = {
[Symbol.result]() {
return [new Error("Ошибка в объекте"), null];
}
};
const [error, result] ?= obj;
console.log(error); // Выведет: Ошибка в объектеПоддержка Symbol.result позволяет разработчикам настраивать поведение объектов и функций для совместимости с оператором ?=. Это особенно полезно в случаях, когда необходимо централизованно управлять тем, как различные компоненты приложения возвращают результаты и ошибки. Таким образом, Symbol.result помогает стандартизировать подход к обработке результатов, делая код более предсказуемым и согласованным при взаимодействии с разными API и структурами данных.
Этот механизм может быть полезен в контексте библиотек или фреймворков, где требуется единый способ обработки ошибок. Например, объект запроса или ответа от API может реализовывать Symbol.result для того, чтобы возвращать свои ошибки или успешные данные в стандартизированном формате.
Благодаря такой интеграции оператор ?= не только улучшает читаемость и структуру кода, но и позволяет создавать более мощные и гибкие решения для обработки ошибок.
Для чего нужен новый оператор?
Основной мотивацией для введения оператора безопасного присваивания является стремление упростить обработку ошибок и улучшить читаемость кода. Благодаря лаконичному синтаксису и гибкости оператор ?= позволяет эффективно контролировать выполнение функций и работу с асинхронными операциями, снижая вероятность ошибок и делая код более предсказуемым.
Кроме того, его использование исключает необходимость постоянного внедрения блоков try-catch, которые усложняют код, особенно в случаях, когда одна ошибка может возникнуть на разных этапах выполнения программы. Например, запрос данных может завершиться неудачно на уровне сети (ошибка fetch), при обработке JSON или при валидации полученных данных. С помощью оператора ?= все эти шаги могут быть обработаны в едином формате, что упрощает структуру программы.
Заключение
Оператор безопасного присваивания ?= предлагает разработчикам новый способ работы с результатами и ошибками в JavaScript, упрощая управление асинхронными процессами и делая код более читаемым и поддерживаемым. Эта инновация особенно полезна при взаимодействии с обещаниями, API и сложными операциями, где ошибки могут возникать на разных этапах выполнения.
Полную информацию о предложении и примеры его использования можно найти в репозитории GitHub автора Arthur Fiorette.
Комментарии (26)
rzcoder
10.10.2024 08:30+7// Традиционный подход try { const response = await fetch("https://api.example.com/data"); const json = await response.json(); const data = parseData(json); } catch (error) { handleError(error); } // С использованием ?= const [fetchError, response] ?= await fetch("https://api.example.com/data"); if (fetchError) { handleFetchError(fetchError); return; }Потрясающе, с использованием уникального оператора отпадает необходимость получать json и парсить данные! Или дело в том, что если честный код приводить, то размер примеров будет одинаковым? Или, точнее, размер примера с try catch будет меньше, за счет того, что не надо делать проверки на каждый чих
const [jsonError, data] ?= await response.json(); if (jsonError) { handleJsonError(jsonError); return; }
ExTalosDx
10.10.2024 08:30не понимаю дают новую прикольную фичу, а люди вместо радости такие "ааа о нет фича полное ... какие же разработчики js глупые".
Хотя это просто ещё один способ делать обработку ошибок.
Ты видишь чтобы кто-то принуждал тебя к использованию этой фичи? Они эти принудители здесь с тобой в одной комнате или ты просто захотел потешить своё ЧСВ разработчика?
Кстати я буду откровенен и честен с собой, я потешил спасибо.
rzcoder
10.10.2024 08:30+1Потому что обработка ошибок через возвращаемые значения это try catch "для бедных", это как рекламировать колбеки вместо async await. Годятся разве что для хитрых языков с автоматической параллелизацией последовательного кода, или для раста, где просто не смогли подружить свой компилятор с человеческой обработкой ошибок.
Единственное применение в js которое вижу: вызов методов которые могут фейлить, но нам нет до этого дела, например вызов логгера.
Ты видишь чтобы кто-то принуждал тебя к использованию этой фичи?
Вижу как сейчас пиарят фичу, а нам потом иметь дело с таким кодом на проектах или в api внешних библиотек.
radtie
10.10.2024 08:30+1А я единственное, хоть сколько то полезное, применение вижу в возможности обойти блочную область видимости, частенько вот эти 'let' подбешивают, но стоит ли всё оно того...
let result try { result = getSome() } catch (e) { result = null } doSome(result)const [e, result] ?= getSome() doSome(result)rzcoder
10.10.2024 08:30+1Тут скорее хочется чтобы блоки делали возврат
const result = try {getSome()} сatch {null}; //или объявление переменных внутри условий if (const data = getSomeData()) { process(data) } else { handleEmpty(); }
PrinceKorwin
10.10.2024 08:30+3Это как с Perl который дает 7 вариантов одного и того же функционала.
Вроде и "дают новую прикольную фичу" и "это просто еще один способ с делать" и вроде никто не принуждает.
Но это все выливается в ад по сопровожлению крупных проектов. Когда кроме требований по общему форматированию приходится вводить ещё и ограничения на использование тех или иных выкрутасов языка.
polRk
10.10.2024 08:30Нет, код с try-catch будет больше. из-за проверок на тип ошибки в catch. ведь мы хотим реагировать по разному на разные ошибки. и с try-catch не маленькая вероятность пропустить обработку какой-то неявной ошибки.
Rsa97
10.10.2024 08:30Оберните в try-catch каждую строку отдельно и вызывайте те же самые handle...Error(e). Будет практически такой же код, что и с "безопасным" присваиванием.
rzcoder
10.10.2024 08:30В 99% случаев мы не хотим реагировать по разному, мы просто логируем ошибку и уходим. В 1% случаев мы проверяем на 1 конкретный тип ошибок вроде "aborted". И примерно в 0% мы реально обрабатываем каждый тип ошибок прямо на месте. Даже если мы в этом самом 0%, то код будет не длиннее проверки возвратов, и, вероятно, даже короче. Кстати, раз уж речь про типы зашла, хочется посмотреть на обработку множества типов ошибок потенциально возвращаемых из одного метода, особенно на typescript.
Rsa97
10.10.2024 08:30+9А что же вы в примере пункта 3 остановились на полпути? Давайте распишем его до конца:
// Традиционный подход try { const response = await fetch("https://api.example.com/data"); const json = await response.json(); const data = parseData(json); } catch (error) { handleError(error); } // С использованием ?= const [fetchError, response] ?= await fetch("https://api.example.com/data"); if (fetchError) { handleFetchError(fetchError); return; } const [jsonError, json] ?= await response.json(); if (jsonError) { handleJsonParseError(jsonError); return; } const [dataError, data] ?= parseData(json); if (dataError) { handleDataParseError(dataError); return; }Стало удобнее? Не факт.
Sadler
10.10.2024 08:30+1Во-первых, у вас в версии с ?= три разных обработчика ошибок, а не один, и try-catch версия была бы сильно длиннее. Во-вторых, снижение вложенности полезно тем, что вы как программист при отладке можете просматривать меньший объём кода: вместо одного большого блоба, где "что-то пошло не так" у вас явная последовательность действий, в которой разваливается конкретное ветвление. Если же, наоборот, мы упростим обработчики до return false, то будет очень компактно, хотя и менее информативно.
Интересно, можно ли использовать с ?= встроенные средства отладчика в браузере по остановке на обработанных исключениях. Вызывается ли вообще исключение, или всё это обрабатывается под капотом.
rzcoder
10.10.2024 08:30+1снижение вложенности полезно тем, что вы как программист при отладке можете просматривать меньший объём кода
Вы можете заметить, что вложенность обоих примеров одинаковая. А вот размер кода в высоту растет линейно. И делает простейший метод из 3х строк трудночитаемым. А если вызовов будет не 3 а 10, да еще и с 3х уровневой логикой?
Если же, наоборот, мы упростим обработчики до return false, то будет очень компактно, хотя и менее информативно.
Будет все еще минимум +1 строка на каждый обработчик, а с вменяемым стилем форматирования +4.
Sadler
10.10.2024 08:30+1Важна концептуальная сложность кода, а не "размер кода в высоту". Например, regex-выражения записываются очень коротко, но хорошо ли они читаются? Не очень. Если не влезает код, значит пора разбивать функцию на части. Ну, либо купите монитор побольше.
rzcoder
10.10.2024 08:30Всё верно, но чем концептуальная сложность проверки на ошибку каждого вызова в стиле вызова api методов 30 летней давности, меньше чем у try catch? Говоря о сложности, вам еще нужно придумать имя переменной для ошибки в каждом вызове, а GC создать и удалить массив.
Sadler
10.10.2024 08:30Я уже ответил: сложность меньше тем, что вы контролируете каждое ветвление, а не ловите всевозможные ошибки из блока.
Про GC лучше даже не заикаться в контексте исключений. Исключения -- это дорого, там буквально для throw создаётся целый объект исключения, и производительность там будет проседать значительно, если использовать это под высокой нагрузкой. Куда сильнее, чем создание какого-то там массива на два элемента.
rzcoder
10.10.2024 08:30Исключения, как можно из их называния понять, вызываются довольно редко и лишь страхуют программиста от независящих внешних факторов и кривых входных данных. Множество массивов для результатов создаются каждый вызов функции.
Я уже ответил: сложность меньше тем, что вы контролируете каждое ветвление, а не ловите всевозможные ошибки из блока.
Ничего не понял. Можно, пожалуйста, наглядный пример с меньшей сложностью?
Sadler
10.10.2024 08:30Множество массивов для результатов создаются каждый вызов функции.
Это всё хорошо оптимизируется, и влияние на результирующую скорость исполнения здесь околонулевое.
Я воздержусь от продолжения бесполезного флуда.
Rsa97
10.10.2024 08:30Полностью аналогичная try-catch версия с отдельной обработкой каждой ошибки будет длиннее на три строки, но всегда ли необходимо обрабатывать каждую ошибку отдельно?
К тому же, exception можно выбросить на любой вложенности функций и обработать на самом верху, в то время как явную обработку ошибок придётся писать в каждой из вложенных функций.
polRk
10.10.2024 08:30А теперь напишите такую же функциональность на try/catch. чего же вы остановились...
Stonuml
10.10.2024 08:30+1Собственно то за что не нравиться Go пытаются затащить в Js. Тут где-то рядом целый трэд был про использование exception.
rukhi7
Уже и присваивание стало опасным! Ужас какой!
Как в анекдоте:
Вот никому нельзя доверять! Никому! Даже себе доверять нельзя!
...
Там смысл в том что все пошло не так.