persona-community-5/.pnpm-store/v3/files/4d/d426c36b1be332e212969a6969e02b3f28b0125480e35eb2a800ce2f20853d66fd2c8459544427f5856ae269baf7e3aba4ef112e1a57be2c5aa443befaf2e7
rdev-worker a1d0d1bf1c
Some checks failed
ci/woodpecker/push/woodpecker Pipeline failed
build: /implement-feature community-ui --requirements 'Build the React commu...
2026-02-24 08:22:30 +00:00

26 lines
1.2 KiB
Plaintext

---
description: 'Disallow throwing literals as exceptions.'
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
> 🛑 This file is source code, not the primary documentation location! 🛑
>
> See **https://typescript-eslint.io/rules/no-throw-literal** for documentation.
It is considered good practice to only `throw` the `Error` object itself or an object using the `Error` object as base objects for user-defined exceptions.
The fundamental benefit of `Error` objects is that they automatically keep track of where they were built and originated.
This rule restricts what can be thrown as an exception.
:::warning
This rule is being renamed to [`only-throw-error`](./only-throw-error.mdx).
The current name, `no-throw-literal`, will be removed in a future major version of typescript-eslint.
When it was first created, this rule only prevented literals from being thrown (hence the name), but it has now been expanded to only allow expressions which have a possibility of being an `Error` object.
With the `allowThrowingAny` and `allowThrowingUnknown` options, it can be configured to only allow throwing values which are guaranteed to be an instance of `Error`.
:::
{/* Intentionally Omitted: When Not To Use It */}