Hono RPC によるエレガントなエラー処理とエンドツーエンドのタイプセーフティ

私は JavaScript のエラー処理に対して常に愛憎の感情を抱いてきました。 try-catch ブロックへの依存と例外のスローは他の人にとってはうまくいくかもしれませんが、私は時々イライラすることがあります。

次の典型的な JavaScript エラー処理パターンを考えてみましょう:

async function fetchData(url) {
  try {
    const response = await fetch(url);
    if (!response.ok) {
      throw new Error(`HTTP error! Status: ${response.status}`);
    }
    const data = await response.json();
    console.log(data);
  } catch (error) {
    console.error("Error fetching data:", error.message);
  }
}

これはコード量が多く、エラーの種類はまだわかりません。

私の意見は、エラーに対処するときは、エラーの原因、発生場所、エラーの種類を知り、すぐに対処する必要があるということです。特にサーバー環境にいる場合はそうです。 私にとって

---

Golangのやり方

私は、golang がエラーを処理する方法と同様に、基本的にエラーを値として処理することを好みます。

data, err := getData()
if err != nil {
  // handle error
}

この方法では、エラーをすぐに処理できるため、エラーが発生した場合に残りのコードが実行されることを心配する必要がありません。

Supabase は、supabase-js ライブラリで同じことを行います。

const { data, error } = await supabase.from("users").select("*");
if (error) {
  // handle error
}

---

Hono RPC による適切なエラー処理

ショーの主役について話しましょう

const onSubmit = async (data: SignUpSchema) => {
  const res = await callRpc(api.auth.signup.$post({ json: data }));

  if (res.error) {
    toast.error(res.error);
    return;
  }

  toast.success("Account created successfully");
  router.navigate({ to: "/" });
};

この関数はあまり目立たないかもしれませんが、RPC 経由でタイプセーフな JSON パラメーターを提供します。すべてのエラーを処理し、エンドポイントの戻り値の型に基づいて RPC 定義から推論されたデータ型で、データまたはエラーを含むオブジェクトを返します。

---

適切なエラー処理の設定

公式ドキュメントを使用して Hono Rpc をセットアップします

Hono エラー ハンドラーのセットアップ

バックエンドは常にエラー メッセージとステータス コードを含むテキスト応答を返す必要があります。

export const errorHandler = (err: Error | HTTPException, c: Context) => {
  console.log("=== Caught Error ===");
  if (err instanceof HTTPException) {
    return c.text(err.message, err.status);
  }
  if (err instanceof z.ZodError) {
    return c.text(err.errors.map((err) => err.message).join(",\n"), 400);
  }
  console.error(err);
  return c.text("Something went wrong", 500);
};

// Add as a errorHandler on the Hono instance
const app = new Hono();
app.onError(errorHandler);

Hono のドキュメントに基づいて、次のように HTTPException をスローする必要があります

import { HTTPException } from "hono/http-exception";

app.post("/", async (c, next) => {
  if (somethingWentWrong) {
    throw new HTTPException(401, { message: "Custom error message" });
  }
  return c.json({ message: "Success" });
});

エラーが発生した場合、常にエラー メッセージとステータス コードを含むテキスト応答を受け取ることがわかりました。

---

3. フロントエンドでのエラー ハンドラーのセットアップ

import { ClientResponse, hc } from "hono/client";
import type { ApiRoutes } from "../../../backend/app";
const client = hc<ApiRoutes>("/");

export const callRpc = async <T>(
  rpc: Promise<ClientResponse<T>>
): Promise<{ data: T; error: null } | { data: null; error: string }> => {
  try {
    const data = await rpc;

    if (!data.ok) {
      const res = await data.text();
      return { data: null, error: res };
    }

    const res = await data.json();
    return { data: res as T, error: null };
  } catch (error) {
    return { data: null, error: (error as Error).message };
  }
};

export default client.api;

callRpc は、RPC 定義に基づいてデータの型を自動的に推測し、データまたはエラーのいずれかを含むオブジェクトを返します。

---

4. 使用方法

送信するものから受信するものまで、すべてがタイプセーフです

const onSubmit = async (data: SignUpSchema) => {
  const res = await callRpc(api.auth.signup.$post({ json: data }));

  if (res.error) {
    toast.error(res.error);
    return;
  }

  toast.success("Account created successfully");
  router.navigate({ to: "/" });
};

私はこのように設定されたコードベースで作業していますが、これまでで最もスムーズな開発者エクスペリエンスです。それを共有するためにここにいます。

---

欠点

• バックエンドは、エラーの場合はテキストを返し、成功の応答では JSON を返すことに制限されています
• このパターンを実行すると、JavaScript でエラーを処理する慣用的な方法から移行します
• エラーをすぐに処理する必要がありますが、これは希望どおりではない可能性があります

以上がHono RPC によるエレガントなエラー処理とエンドツーエンドのタイプセーフティの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。