Property 'status' does not exist on type 'Error' in TS

avatar

Borislav Hadzhiev

Wed Mar 23 20223 min read

Property 'status' does not exist on type 'Error' in TS #

The error "Property 'status' does not exist on type 'Error'" occurs because the status property is not available on the Error interface. To solve the error, add the specific property to the Error interface or create a custom class that extends from Error.

property status does not exist on type error

Here is an example of how the error occurs.

index.ts
const err = new Error('Something went wrong'); // ⛔️ Property 'status' does not exist on type 'Error'.ts(2339) err.status = 500; // ⛔️ Property 'code' does not exist on type 'Error'.ts(2339) console.log(err.code);

The reason we got the errors in the example above is because the status and code properties don't exist on the Error interface.

By default, the Error interface has the following properties:

index.ts
interface Error { name: string; message: string; stack?: string; }

To get around this, we can add the properties to the Error interface.

index.ts
interface Error { status?: number; code?: number; } const err = new Error('Something went wrong'); err.status = 500; console.log(err.status); // 👉️ 500 err.code = 500; console.log(err.code); // 👉️ 500

TypeScript will merge the declared from you Error interface with the original Error interface, so when you use the Error object, you will be able to access methods and properties from both interfaces.

An alternative solution is to create a custom class that extends from Error.

index.ts
export class CustomError extends Error { status = 400; constructor(status: number, message: string) { super(message); this.status = status; // 👇️ because we are extending a built-in class Object.setPrototypeOf(this, CustomError.prototype); } getErrorMessage() { return 'Something went wrong: ' + this.message; } } const err = new CustomError(500, 'Something went wrong'); console.log(err.status); // 👉️ 500 console.log(err.message); // 👉️ "Something went wrong"

We created a CustomError class that extends from Error.

Whenever you extend a class, you have to call super() before being able to use the this keyword.

We also had to use the Object.setPrototypeOf method, because we are extending a built-in class.

You have to call Object.setPrototypeOf immediately after calling super().

You have to use this approach for any classes that extend built-ins and for any of the subclasses of CustomError.

Basically, we have to manually adjust the prototype. If you want to read more on why this is needed, check out this section of TypeScript's wiki.

You have to use the instanceof operator if you need to check if a variable stores an instance of CustomError.

index.ts
export class CustomError extends Error { status = 400; constructor(status: number, message: string) { super(message); this.status = status; // 👇️ because we are extending a built-in class Object.setPrototypeOf(this, CustomError.prototype); } getErrorMessage() { return 'Something went wrong: ' + this.message; } } const err = new CustomError(500, 'Something went wrong'); // 👇️ Check if instance of CustomError if (err instanceof CustomError) { console.log(err.status); // 👉️ 500 console.log(err.message); // 👉️ "Something went wrong" }

The instanceof operator serves as a type guard.

If you throw a CustomError in some other place in your code, you need a way to check if the caught error is a CustomError before you are able to access CustomError specific properties and methods.

This works in the same way as you would check if an error is an instance of the Error object in a catch block.

index.ts
async function getData() { try { await Promise.resolve('hello world'); } catch (err) { // 👉️ err is unknown here // can't access Error specific properties if (err instanceof Error) { console.log(err.message); // 👈️ err is type Error here } console.log('Unexpected error: ', err); } }

The err variable has a type of unknown in the catch block, so we have to the instanceof operator before we are able to access the message property.

This is needed, because there's no way to be sure that the caught error will be of specific type ahead of time.

Note that any classes that subclass CustomError also need to manually adjust the prototype.

Use the search field on my Home Page to filter through my more than 1,000 articles.