Hacker News Reader

”One thing that burned me bad though was that without a `try` anywhere, my 100 line async function failed silently. I think because its transpiling to promises and nothing was handling a failed returned promise. Really really frustrating.”

This is a promise thing, it doesn’t really have to do with async/await or transpiling.

Node.js and some browsers have a warning or event you can listen for https://developer.mozilla.org/en-US/docs/Web/Events/unhandle...

It's not just certain environments, I'm fairly sure that if you use a normal promise polyfill like babel-polyfill provides, then unhandled promise rejection failures will always trigger window.onunhandledrejection, which is analogous to window.onerror (unhandled promise rejections in async code are the equivalent of unhandled exceptions in sync code). If you set up both of those to do any error handling/reporting that you need, you can avoid any issues of promise rejections getting swallowed.

> One thing that burned me bad though was that without a `try` anywhere, my 100 line async function failed silently.

You should be bubbling errors up to some top level and at least catching them there.

Wrapping entire async-fn bodies with try/catch (or outright overuse of try/catch) is probably the most ubiquitous beginner mistake I see in modern Javascript.

For example, imagine if your top level was even just run().catch(console.error).

I really need to find where to do that. It's inside a redux dispatch and I dunno... Nothing is catching them. It's just silent.

Its silent because its inside another promise and that one have catch that is swallowing it somewhere in the chain.

"...without a `try` anywhere, my 100 line async function failed silently."

I've played with catchify a bit.

https://github.com/majgis/catchify

https://www.npmjs.com/package/catchify

Feels less awful. But I'm still ambivalent. Callbacks vs promises vs async/await vs catchify's golang style error propagation. Yay.

I intended to weave in timeouts and tracing (metrics). See if that makes nodejs dev work sufferable. Maybe a catchify & timeoutify & traceify hybrid will keep me from playing in traffic.

async/await works best when all of your async code uses it, so it’s kind of silly to pass a callback into an async function like this example from the article that inspired catchify:

    async function asyncTask(cb) {

async functions return a promise that rejects if an error is thrown (either directly or by a promise that is awaited on), so there’s no need to handle every error if you’re ok with it just propagating.

No need to get any extra library involved; the standard library handles your case:

  let result = await Promise.all(collection.map(expensiveFunction));

(I’m presuming expensiveFunction is an asynchronous function; if it is instead a synchronous function, then don’t bother about the Promise.all part, just do it all at once asynchronously, as the effect will be the same: `new Promise(resolve => setTimeout(() => resolve(collection.map(expensiveFunction))))`.)

Your last snippet only defers the code execution to the next iteration of the event loop. If it's synchronous, Since it's "blocking" anyways (no IO or network requests), why not just `let result = collection.map(expensiveFunction)` ?

You could toss the expensive function in a web worker to make it non blocking.

Too expensive to do in one frame. Too cheap to use a worker. Alas. :)

Depending on the data you are sending transferrable objects could be your solution.

Typed arrays can be zero-copy transferred to a worker extremely quickly, modified, then transferred back if needed.

No costly copying or cloning needed. But it won't work with just objects, just typed arrays.

Yep. In my example I want each iteration of map to be queued so they all occur whenever there isn't rendering or whatnot to be done.

I was making the assumption that it was completely synchronous, and thus that using a new setTimeout per item wouldn’t be helpful, but I neglected to consider UI responsiveness—and so on reflection such a thing might be useful. Taking that into account, it becomes rather messier:

  new Promise(resolve => {
    const out = [];
    const iterator = collection[Symbol.iterator]();
    function next() {
      const item = iterator.next();
      if (item) {
        setTimeout(() => {
          out.push(expensiveFunction(item.value));
          next();
        });
      } else {
        resolve(out);
      }
    }
    next();
  });

JavaScript’s threading model is rather hostile to expensive CPU-bound functions. Workers are just too hard to use unless you go all in with that architecture. I love being able to work with things like Rayon in Rust.

Especially when used with control flow like for loops and if/else. It's incredible how much cleaner it makes the code.

I use await/async everywhere in my projects but I still have to use try catch.

Am I doing something terribly wrong?

You're probably doing it right