Hi @andsouto, thanks for the report! This is an interesting edge case.

My initial reaction is to regard it as a bug that the Error interface is implemented, not extended, see also #9370. But, I realize that that's something that occurs in a third party library, not one which you have control over modifying...

It may be reasonable to address this by creating an option allowing a list of types to specified as permissible to be thrown, similar to what we've done recently for no-floating-promises (see https://typescript-eslint.io/rules/no-floating-promises/#allowforknownsafepromises).

We'll see what other team members say.

Minimal repro: https://typescript-eslint.io/play/#ts=5.5.2&fileType=.tsx&code=KYDwDg9gTgLgBAE2AYwDYEMrDm9BnPOAMQgjgEsBbMVYS4AOxkIFEopo4BvAKDjizoEEBqgCecBunpwAvHABEACRgwwbDlABKwPJAZ5gCgNx8BwISPFx6BdAHNgALjh4YUcg3umAvjx4wABYcAO6SwGEkEAAUAJTGQA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6AeyfkNvwAto7AO71og6OiiIx7CeDABfEAqA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

We should probably add an allow option for it. There are similar examples such as Remix throwing redirect responses.

such as Remix throwing redirect responses

...why would they do this?

I can see an argument for allowing something that happens to implement a shape like Error - an ErrorLike, if you will. But what possible good reason would one have for throwing something else?

...why would they do this?

This reminds me of https://h3.unjs.io/guide/event-handler as well (which, for instance, powers Nuxt.js), where throwing is basically used for relatively ordinary control flow, with custom data. Now, it looks like createError does return an Error subclass in this case (see the source code), but I don't think it needs to for their usage, and I'd regard that as an implementation detail subject to change. In other words, I think it would be reasonable for someone to want to throw createError({}) in this context even if createError() didn't return an Error subclass (or even if it didn't implement Error/ErrorLike at all and were just a specific kind of object).

But what possible good reason would one have for throwing something else?

There are two reasons I can think of, in general:

1. You want to have a two-way distinction between completion values, but you don't want to force everyone into the tagged union pattern.
2. You want to let the value pierce through the call stack to someone who cares (algebraic-effect-style).

For example, see https://remix.run/docs/en/main/route/error-boundary

Note that there was a duplicate under the old rule name #6226