【Node.js】メソッドチェーン vs try-catch どっちの記法がベスト？

Question

経緯

• タイトルのどちらも似たような処理になる認識ですが、SIerで開発をしているPGとして

Promiseオブジェクトをハンドリングはどちらの記法で実装することがベストなのか興味を持ち投稿いたしました

• 三項演算子を使うべきかどうかと似たようなケースになると思いますが、ご意見・ご回答をくだされば幸いです

前提

• SIerで追加開発・保守運用をするという観点からご意見・ご回答をいただければと思います
• 現場のレベルはJavaがメインで、Node.jsは未経験者がほとんどという想定でお願いします

❓質問事項

Node.js Promise オブジェクトのハンドリングとして、以下2種類の書き方があります
どちらの記法がベストな記法なのかを下記の観点よりご教授いただけないでしょうか？

1. async/await を用いたtry-catch構文でのハンドリング
2. then()/catch()を用いたメソッドチェーンでのハンドリング

観点

• 可読性
• 視認性
• 保守/メンテナンス性
• 拡張性
• その他 追加開発/保守運用で必要な諸々。。。

該当のソースコード

import axios from "axios";

// async/await を用いたtry-catch構文でのハンドリング
export const getData = async () => {
  const url = "https://xxxxx";
  try {
    const res = await axios.get(url);
    // handle success
    console.log(`Response : ${res.data}`);
  } catch (error) {
    console.error(`Error : ${error}`);
  }
}

// then()/catch()を用いたメソッドチェーンでのハンドリング
export const getData = () => {
  const url = "https://xxxxx";
  axios
    .get(url)
    .then((res) => {
      // handle success
      console.log(`Response : ${res.data}`);
    })
    .catch((err) => {
      console.error(`Error : ${err}`);
    });
};

Answer 1

どちらの記法がベストな記法なのか

混在させると悲惨な事になるので
プロジェクトの既存コードに合わせるのが大前提です。

ただし、プロジェクトを立ち上げる場面だとしましょう。
採用条件を選べるのなら絶対にasync/awaitの方を選びます。

ベースはasync/await、
要所要所でPromise流儀の書き方を強いられるので
必要最低限のみPromise流儀の書き方で解決するようにします。

---

何故そうなるのかに関しては歴史を紐解く必要があるので、そちらの解説からします。

まずはコールバック地獄のお話。
質問文で最初から「Promise使いたいです！」って言っているので恐らく既知の箇所と被ってるでしょう。
聞き流してやってください。

JavaScript(Node.js)はシングルスレッドです。
とりあえず書いてある事は一息で実行しようとします。

なのでネットワークやHDDへのアクセスは基本的には待ちません。
関数と達成条件をセットで渡してイベント登録を行い、
「イベントループ」という巡回している機能に代わりに関数を叩いてもらう設計になっています。

まぁ、これが原因で「コールバック地獄」になるんですがね。

JSがシングルスレッドであるがために既存のコードを一息で実行しようとして、
怠惰で後回しにするイベント登録という解決策しか用意されてない以上、
非同期処理を挟む時は、同期処理に帰って来れないのでif・for・try-catchといった制御構文が一切使えません。
(抽出しようと思っても値が帰ってくるまで待たず、持って帰れないので全ての制御構文がすり抜ける)

もし貴方の現場のメンバー全員が、
JavaScriptのルーツはLispなので、それのテクニックを流用してサラッと書けると思いますが、
普段からHaskellやLispで書きまくっている関数型オタクならいざ知らず
手続き型プログラミング言語のJavaを使っている人には相当無理がある要求です。

多分現場のコードはネストだらけの阿鼻叫喚のクソみたいなコードであふれかえるでしょう。

---

Promiseはその「コールバック地獄」を
オブジェクト指向プログラミングのテクニックで解決したものです。

PromiseインスタンスはES2016で正式にJSの仕様として採用されており、
Node.jsなら1系未満でも対応しています。

Promiseのインスタンスに対して.then(fn)や.catch(fn)メソッドを叩くだけなので
初期のJSのコールバック地獄から比べれば雲泥の差です。

しかし、所詮はオブジェクト指向プログラミングのテクニックでゴリ押ししただけ。
非同期処理を挟む時は、同期処理に帰って来れないのでif・for・try-catchといった制御構文が一切使えません。
この大問題は一生解決しません。(←これが言いたいからコールバック地獄の話した)

コードで説明しましょう。

// このURL一覧にアクセスしてHTMLを持ち帰りたい
const urls = [
  "http://example.com/1",
  "http://example.com/2",
  "http://example.com/3",
  "http://example.com/4",
];

// こう書けばよくね？
Promise.all(
  urls.map(url =>
    axios.get(url).then(res => res.data)
  )
).then(results => {
  console.log(results);
});

//  → 同時接続しすぎなので一度に1通信だけにして欲しいと顧客に言われた
// しゃあない、for文使って数珠つなぎにするか
let promise = Promise.resolve(null);
const results = [];
for (const url of urls) {
  promise = promise
    .then(() => axios.get(url))
    .then(res => results.push(res.data))
  });
}
// 同期処理には帰ってこれないのでresultsの中身を見たければpromise.thenを叩くしか無い
promise.then(() => {
  console.log(results);
});

なんか雲行きが怪しくなってきましたね。
あっ、これにエラー処理追加しないといけないですね。

let promise = Promise.resolve(null);
const results = [];
for (const url of urls) {
  promise = promise
    .then(() => axios.get(url))
    .then(res => results.push(res.data))
    // ココに書くと失敗したURLを飛ばして次に行く
    .catch(err => console.log(err));
}
promise
  // 上記ではなくここだけに書くと、失敗したらそれ以降通信しない
  .catch(err => console.log(err))
  .then(results => console.log(results));

(一発書きなので多分動くと思いますが自信薄)

エラー処理挟むだけで2通りに分岐しましたね。
リーダーの貴方は部下が書いてきたこのコードを読んで、
「仕様と違うよね？直して」「仕様通りだね、さすが！」を判別しなければなりません。

私は毎日こんなコード読みたくありません。

可変長の配列のURLを順次アクセスするもっとスマートに書く方法があるかもしれないですが、
私のJS力だとちょっとこれが限界ですね。
私だったら「やりたいことに対するノイズ多すぎ、やってられるか！」と思いますね。

Promiseには限界があると思います。

---

んでようやくasync/await構文
これはES2017のPromiseの次に実装されたPromiseをよしなに操る糖衣構文です。

async関数を定義すると、必ずPromiseのインスタンスを返します。

• await Promise: .then(val => {})に変換され、valを同期処理っぽく取り出せる
• return val: resolve(val)に変換される
• try-catch: .catch(中身)に変換される
• if文: 謎の力でよしなにやってくれる！
• for文: 謎の力でよしなにやってくれる！

もうね、if,for,try-catchが非同期処理に混ぜて良いだけで神ですよ。
出るの1年おせえよES2016の時点で実装しろよ。

いやいや出てくれただけで神です。

// async関数を定義しないとawait構文使えないからね
const main = async () => {
  const urls = [
    "http://example.com/1",
    "http://example.com/2",
    "http://example.com/3",
    "http://example.com/4",
  ];

  // 最初に書いたPromise.allを使うパターンも何気に恩恵受けてる
  // Promise.allはエラー処理周りで融通効かないので質問文の条件を加味すると頻度は下がると思う
  const results1 = await Promise.all(
    urls.map(async url => {
      const res = await axios.get(url);
      console.log(res.data);
      reutrn res.data;
    })
  );
  console.log(results1);

  // 途中でエラー吐いたら即停止したい
  const results2 = [];
  try {
    for (const url of urls) {
      const res = await axios.get(url);
      console.log(res.data);
      results2.push(res.data);
    }
    console.log(results2);
  } catch (e) {
    console.error(e);
  }

  // エラー吐いたURLは無視して次へ行きたい
  const results3 = [];
  for (const url of urls) {
    try {
      const res = await axios.get(url);
      console.log(res.data);
      results3.push(res.data);
    } catch (e) {
      console.error(e);
    }
  }
  console.log(results3);
};

// 実行
main();

// こんな風にasyncのアロー関数を括弧で包んで即時実行しても良い
(async () => {
  // 内部の処理
})();

内部的にPromiseを使いまくっているとはいえ、
Promise臭みたいなのはコードからほぼ消えました。
Promiseだけで全部やれ！の地獄を思えば雲泥の差です。

これなら流石に現場の人間、全員読めるし処理追えるでしょ……

まぁ、一部setTimeoutみたいなのはPromise使わないと上手く書けないので
そういう所は詳しい人がライブラリ化して別ファイルにしちゃいましょう。
そこだけ紹介して終わります。

// setTimeoutを改造したsleep関数つくるよ
const sleep = ms => new Promise(resolve =>
  setTimeout(resolve, ms)
);

const main = async () => {
  console.log(1);

  // 3秒待ちたい
  await sleep(3000);

  console.log(2);
};

Comments

[PePePeT_i_C]

ご丁寧な解説ありがとうございます！

質問の投稿で「どちらも似たような処理になる認識ですが」と記載しましたが、
制御構文がすり抜けてしまうことを完全に失念していました。。。

歴史的経緯からお話頂けて分かりやすく勉強になり、文章としてもとても面白かったです！！
ありがとうございました????????