What Can You Throw in JavaScript?

Any value at all. The language does not check what you throw, so a string, a number, an object or an Error instance are all valid, and the catch block receives exactly what you threw.

// Anything can be thrown.
try {
  throw "a plain string";
} catch (err) {
  console.log(typeof err, err);   // "string" "a plain string"
}

try {
  throw { code: 404, message: "Not found" };
} catch (err) {
  console.log(err.code);   // 404
}

// Error objects carry a stack.
try {
  throw new TypeError("bad type");
} catch (err) {
  console.log(err instanceof Error);   // true
  console.log(err.name);               // "TypeError"
  console.log(err.stack.split("\n")[0]);
}

The freedom is real, and it is also a trap. Because a thrown value might not be an Error, any code that catches an error has to check before it reads the message property. Code that assumes err.message always exists will produce a confusing failure when something throws a string, and that happens more often than you would like in older code bases.

There is a good reason to prefer Error objects even though they are not required. They carry a name that tells you the category of the failure, a stack that tells you where it came from, and a cause that lets you chain errors together. A thrown string carries none of that, so all the useful context has to be formatted into the string by hand, which makes the result harder to log and impossible to inspect programmatically.

One more thing worth knowing. Throwing inside a catch block is a perfectly normal thing to do, and it is how you add context to a low level failure. But be careful about throwing from a finally block, because that will replace whatever the try block was in the middle of doing.

Always throw Error objects. The language lets you throw anything, but nothing good comes from throwing a string.

The reasons are practical. An Error has a name, so the catch block can tell a TypeError from a RangeError without parsing text. It has a stack, so when it reaches a log you can see the call path that led to the failure. It has a cause, so you can wrap a lower level failure without losing it. And the message can stay a plain human sentence, because the machine readable information lives in the other properties.

Throwing a string also forces a decision at every catch site. The catch block cannot know whether it received a string, an object or an Error, so it has to guard against all of them before it can read anything. That guard is noise in code that is already handling an exceptional path, and it is exactly the code you want to keep simple.

There is one nuance worth mentioning. Sometimes you want to throw a value that is not an error at all, for example to implement a control flow signal such as a cancellation or an early exit. In that case a sentinel value or a dedicated error subclass is the right tool, and the convention is to give it a clear name so that callers can recognise it and handle it specially.

The exception to the rule is third party code you do not control. If a library throws strings, wrap them in an Error at the boundary so that the rest of your code only ever sees one shape.

Catch the original error and throw a new one that mentions where you are, keeping the original as the cause so nothing is lost.

function readConfig(path) {
  try {
    return JSON.parse(path);
  } catch (err) {
    // Rethrow with context, keeping the original as the cause.
    throw new Error(`Could not parse ${path}`, { cause: err });
  }
}

try {
  readConfig("{ not json");
} catch (err) {
  console.log(err.message);                        // "Could not parse { not json"
  console.log(err.cause instanceof SyntaxError);   // true
}

The cause option is the important part. It was added to the Error constructor so that a wrapper can say what it was trying to do without discarding the underlying reason. The original error is still available, still has its own stack, and still has its own type, so a logging layer can walk the chain and record the whole story.

If you are working with an older runtime, the same thing can be done by assigning the cause property yourself after creating the error, or by using a custom error class that sets it in the constructor. The option syntax is simply the tidy version of that.

Two rules for doing this well. Keep the wrapper message about your layer and not about the inner failure, so the messages read as a chain rather than as a repetition. And only wrap once. If every layer adds its own wrapper you end up with a stack of near identical messages, so it is usually better for the layer that actually understands the failure to produce the useful message and for the layers above it to stay quiet or to add only genuinely useful context.