Zig 0.16 - async здорового человека

новомодном dart

Поржал

новомодном dart

Поржал

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

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

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

Фигасе.
А я только-только, буквально вот-вот, успел флаттером восторгнуться.
Прикольную штуку они организовали, хоть и поперек всей индустрии. Но прикольно.

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

Flet флатер в пипоне ваще будущее в прошедшем

Обмажутся своим pyodide webasembly и молодюж партят

что такое «async заражение» - в курсе, нет?

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

Писал много кода на JS, никаких проблем с async не испытывал.

По-мне async в JS реализован просто идеально и ничего лучше уже не придумать.

Значит мало писал.

В JS промисах есть противная асимметрия – когда запускается промис, он выполняет какую-то работу и результат этой работы хранится внутри до тех пор, пока его потребуешь при помощи await.

Но если внутри промиса происходит ошибка, то она должна быть обработана сразу. Если нет на промисе обработчика то возникает Unhandled Promise Rejection.

Вот пример простого типично кода: загружаем откуда-то файлы параллельно запуская их обработку и дожидаемся результатов обработки. Все в try-catch, ни к чему не подкопаться. Но, зараза, примерно каждый 5й раз все наворачивается с эксепшеном без какого-либо стектрейса. Браузеры такое проглатывают, но современные NodeJS останавливают весь процесс и надпись «all files processed» не появляется.

function randWait(sec: number): Promise<void> {
    return new Promise((resolve, reject) => {
        setTimeout(resolve, sec * 1000 * Math.random())
    })
}

async function loadFile(): Promise<{}> {
    await randWait(0.5)

    console.log('file loaded')

    return {}
}

async function processFile(file: {}): Promise<void> {
    await randWait(2)

    if (Math.random() < 0.3) {
        throw new Error('failed to process file')
    }

    console.log('file processed')
}

async function main(): Promise<void> {
    const promises: Promise<void>[] = []

    try {
        for (let i = 0; i < 5; ++i) {
            const file = await loadFile()

            // накапливаем промисы в массиве
            promises.push(processFile(file))
        }

        // параллельно дожидаемся результатов обработки
        const values = await Promise.allSettled(promises)
        console.dir(values)
    } catch(err) {
        console.error(`catch error ${err}`)
    }

    console.log('all files processed')
}

main()

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

В тех же плюсах, например, если внутри Future выскакивает неперехваченное исключение, оно сохраняется внутри и при вызове метода get() воспроизводится еще раз для того, чтобы можно было его нормально обработать. Что курили разработчики JS во время разработки их async/await не понятно.

Значит мало писал.

Достаточно.

В JS промисах есть противная асимметрия – когда запускается промис, он выполняет какую-то работу и результат этой работы хранится внутри до тех пор, пока его потребуешь при помощи await.

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

Глупости. Нет никакой асимметрии и ошибку можно обработать когда угодно и сколько угодно раз.

Если нет на промисе обработчика то возникает Unhandled Promise Rejection.

Ну возникнет и возникнет, в чём проблема-то? Это просто упрощение отладки и ни на что не влияет кроме появления строчки в логах.

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

Ну возникнет и возникнет, в чём проблема-то? Это просто упрощение отладки и ни на что не влияет кроме появления строчки в логах.

Почему же тогда у меня на этом скрипте современная nodejs падает?

Касательно твоего кода - он кривой, поэтому и работает кое-как. Или ставь await processFile или делай нормальную параллельность. Сейчас ты файлы грузишь последовательно, но при этом зачем-то пытаешься запускать processFile параллельно с загрузкой следующего файла. Твой try-catch не имеет смысла, т.к. Promise.allSettled не падает, а ты, судя по всему, рассчитывал на это.

Почему же тогда у меня на этом скрипте современная nodejs падает?

Потому, что nodejs проектировали идиоты. Но ты можешь запускать свой скрипт через node --unhandled-rejections=none

Или ставь await processFile или делай нормальную параллельность.

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

Как исправить этот код, чтобы не засиралась браузерная консоль и не падала нода без костылей, вроде флагов и глобальных обработчиков unhandled rejections?

Не проверял, но примерно идея, думаю, понятна, как-то так можешь свой код переписать:

async function loadAndProcess() {
  async file = await loadFile();
  async result = await processFile(file);
  return result;
}

async function main(): Promise<void> {
  const promises: Promise<void>[] = []
  for (let i = 0; i < 5; ++i) {
    const promise = loadAndProcess();
    promises.push(processPromise)
  }
  const values = await Promise.allSettled(promises)
  console.dir(values)
  console.log('all files processed')
}

Ну или просто const promise = loadFile().then(processFile)

Тут вся фишка в том, чтобы вызвать Promise.allSettled моментально, в том же тике, что и создание Promise-ов. Он уже сам проставит им reject обрабтичики и всё везде будет работать нормально.

То, что ты написал изначально - справедливо, но это просто идиотизм конкретной реализации в node.js, а не проблема языка. В самом языке никакой необходимости немедленно добавлять обработчик к promise не имеется. Я немного погуглил и, собственно, node.js это относительно недавно поменяли, изначально такого поведения не было. Мотивировали заботой об новичках, которые забывают проверять ошибки.

Как исправить этот код

Если настаиваешь именно на таком поведении, то просто присобачь пустой обработчик:

            const file = await loadFile()
            const processPromise = processFile(file);
            processPromise.catch(()=>{});
            promises.push(processPromise)

Может как-то поэлегантней можно решить, но мне сходу в голову ничего не приходит.

С пустым обработчиком ошибок онри просто будут подавляться

Т.е. в массиве после allSettled ее не будет

Не будут подавляться, в массиве всё будет.

let p = new Promise((_, rej) => rej("e"));
p.catch(() => {});
let ps = await Promise.allSettled([p]);
console.log(ps);

выводит

[ { status: 'rejected', reason: 'e' } ]

но в случае

let p = new Promise((_, rej) => rej("e").catch(() => {}));
let ps = await Promise.allSettled([p]);
console.log(ps);

Ошибки начинают подавляться.

Т.е. ты навешиваешь catch на промис, этот catch возвращает тебе новый промис, но ты его игнорируешь и продолжаешь использовать старый промис без обработчика. Но этот старый промис уже помечен, что на нем висит обработчик, хотя и в реальности не висит, поэтому нет unhandled rejection, но при этом сами ошибки продолжают лететь.

Где-нибудь этому внятное описание сеть?

В MDN есть отличное описание всего API, связанного с веб-технологиями.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

В частности описание метода catch:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/catch

Результат catch это Promise, который либо fulfilled с возвращенным значением из функции, переданной в catch, либо rejected, если переданная функция выбросила исключение. Ну т.е. в случае пустой функции это будет fulfilled promise с undefined значением.

Вроде всё чётко и понятно.

Если вдруг не понимаешь этого момента - на один промис можно навешивать сколько угодно catch-ей и тд. И все они будут вызваны. Т.е. в данном случае мы навешиваем пустой catch только чтобы эту диагностику подавить, а в дальнейшем allSettled повесит свой обработчик рядом с нашим пустым, и это всё сработает как ожидается.

Бездумно чейнить вызовы не стоит, это да. Надо понимать, что где возвращается. Но блин, там API буквально из трёх методов состоит. И это можно сказать базовое API для современного JS. Можно один раз и прочитать.

Спасибо, стало понятнее