[rpc] Typing for DetailedError

[Le0Developer]

What is the feature you are proposing?

Currently parseResponse throws an DetailedError when the fetch has a non-OK status code.
This error is completely untyped.

I propose the following:

1. adding a new function like parseResponseWithError which returns an object (similar to how openapi-ts does it):

const { result, error } = await parseResponse(client.hello.$get())

2. adding a way to force infer a DetailedError (no additional runtime code):

const result = await parseResponse(client.hello.$get()).catch(
  (err: any) => {
    if(err instanceof DetailedError) {
      const e: DetailedError<typeof client.hello.$get> = err;
    }
  }
)

Current workaround, check each possible status code explicitly and then cast the err.data to InferResponseType<typeof client.hello.$get, 4xx>

[JonoGitty]

Happy to take this if nobody has started on it.

Of the two shapes Le0Developer outlined, option 2 (type-only DetailedError<T>) seems the smaller first step: no new runtime surface, no impact on existing callers, closes the untyped err.data gap directly. A generic on DetailedError carrying the request-handler type, paired with the existing InferResponseType for per-status data, should be enough. Roughly:

class DetailedError<R = unknown> extends Error {
  readonly data: InferResponseType<R, ErrorStatusCode>
  // ...
}

Option 1 (parseResponseWithError returning { result, error }) would let callers branch instead of try/catch, but it's a bigger API change and openapi-ts-style returns may not fit where Hono wants to head. Could be a follow-up if option 2 lands and people want it.

@Le0Developer, preference between the two options from your side? Will wait for a maintainer steer on scope (option 2 alone vs both) before coding.

[Le0Developer]

Preferably it's the first option because it avoids cases where you changed the API call but then forgot to change the error type as well (-> desync).
It definitely has its advantages being a (relatively small) typing only change which is why I mentioned it (also the first option would probably include this anyway).

The first would also fix patterns where I first need to define the response variable with a similar explicit type hint before assigning to it in a try catch statement.
It also forces you to handle errors by having the data property be | undefined/mutually exclusive with the error. (Openapi-ts has a throwError option you can pass if you don't want to deal with that)