Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://typescript-eslint.io/rules/only-throw-error below:

only-throw-error | typescript-eslint

Disallow throwing non-Error values as exceptions.

💭

This rule requires type information to run, which comes with performance tradeoffs.

🧱

This is an "extension" rule that replaces a core ESLint rule to work with TypeScript. See Rules > Extension Rules.

This rule extends the base no-throw-literal rule from ESLint core. It uses type information to determine which values are Errors.

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.

Migration from no-throw-literal

This extension rule was formerly known as @typescript-eslint/no-throw-literal. The new name is a drop-in replacement with identical functionality.

This rule is aimed at maintaining consistency when throwing exceptions by disallowing throwing values that are not Error objects.

• ❌ Incorrect
• ✅ Correct

throw 'error';

throw 0;

throw undefined;

function getErrorString(): string {
  return '';
}
throw getErrorString();

const foo = {
  bar: 'error string',
};
throw foo.bar;

class SomeClass {
  
}
throw new SomeClass();

throw new Error();

throw new Error('error');

const e = new Error('error');
throw e;

function getError() {
  return new Error();
}
throw getError();

const foo = {
  bar: new Error(),
};
throw foo.bar;

class CustomError extends Error {
  
}
throw new CustomError();

• Flat Config
• Legacy Config

eslint.config.mjs

export default tseslint.config({
  rules: {
    
    "no-throw-literal": "off",
    "@typescript-eslint/only-throw-error": "error"
  }
});

.eslintrc.cjs

module.exports = {
  "rules": {
    
    "no-throw-literal": "off",
    "@typescript-eslint/only-throw-error": "error"
  }
};

See eslint/no-throw-literal's options.

This rule adds the following options:

interface Options {
  


  allow?: (
    | {
        from: 'file';
        name: string[] | string;
        path?: string;
      }
    | {
        from: 'lib';
        name: string[] | string;
      }
    | {
        from: 'package';
        name: string[] | string;
        package: string;
      }
    | string
  )[];

  


  allowRethrowing?: boolean;

  


  allowThrowingAny?: boolean;

  


  allowThrowingUnknown?: boolean;
}

const defaultOptions: Options = {
  allow: [],
  allowRethrowing: true,
  allowThrowingAny: true,
  allowThrowingUnknown: true,
};

When set to true, this option allows throwing values typed as any.

Examples of correct code with { allowThrowingAny: true }:

When set to true, this option allows throwing values typed as unknown.

Examples of correct code with { allowThrowingUnknown: true }:

When set to true, this option allows throwing caught values. This is intended to be used in order to make patterns involving rethrowing exceptions less painful for users who set allowThrowingAny/allowThrowingUnknown to false.

Examples of correct code with { allowRethrowing: true, allowThrowingAny: false, allowThrowingUnknown: false }:

declare function mightThrow(): void;
declare class SomeSpecificError extends Error {
  
}

function foo() {
  try {
    mightThrow();
  } catch (e) {
    if (e instanceof SomeSpecificError) {
      
      return;
    }

    
    throw e;
  }
}

declare function mightReject(): Promise<void>;

mightReject().catch(e => {
  if (e instanceof SomeSpecificError) {
    
    return;
  }

  
  throw e;
});

declare function log(message: string): void;

function bar() {
  log('starting bar()');
  let wasError = false;
  try {
    
  } catch (e) {
    wasError = true;
    throw e;
  } finally {
    log(`completed bar() ${wasError ? 'with error' : 'successfully'}`);
  }
}

note

While it makes sense to rethrow errors in some cases, it is likely more common that one would want to create a new Error and set its cause appropriately.

function foo() {
  try {
    
  } catch (e) {
    throw new Error('Could not complete foo()', { cause: e });
  }
}

This option takes the shared TypeOrValueSpecifier format to allow throwing values that are not Error objects. While we strongly recommend that you only create custom error classes that extend Error, this option can be useful for throwing errors defined by libraries that do not follow this convention.

Examples of code for this rule with:

{
  "allow": [{ "from": "file", "name": "CustomError" }],
}

Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.

See Troubleshooting > Linting with Type Information > Performance if you experience performance degradations after enabling type checked rules.

• Rule source
• Test source

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4