What is the difference between `throw new Error` and `throw someObject`?

Question

I want to write a common error handler which will catch custom errors thrown on purpose at any instance of the code.

When I did throw new Error('sample') like in the following code

try {
    throw new Error({'hehe':'haha'});
    // throw new Error('hehe');
} catch(e) {
    alert(e);
    console.log(e);
}

Log shows in Firefox as Error: [object Object] and I couldn’t parse the object.

For the second throw the log shows as: Error: hehe

Whereas when I did

try {
    throw ({'hehe':'haha'});
} catch(e) {
    alert(e);
    console.log(e);
}

the console showed as: Object { hehe="haha"} in which I was able to access the error properties.

What is the difference?

Is the difference as seen in the code? Like string will be just passed as string and object as objects but the syntax will be different?

I haven’t explored throwing error object… I had done only throwing strings.

Is there any other way than the above two mentioned methods?

Claim

The problem with throw new Error({prop:val}) is that's not a valid construction of Error. Error has known properties as discussed by Hemant. – Bypass

related: Throwing strings instead of Errors – Wilmer

based on ecma262 they both are the same: creates and initializes a new Error object when called as a function rather than as a constructor. Thus the function call Error(…) is equivalent to the object creation expression new Error(…) with the same arguments. Spec in tc39.es/ecma262/#sec-error-constructor – Disc

Answer 1

The difference between 'throw new Error' and 'throw someObject' in javascript is that throw new Error wraps the error passed to it in the following format −

{ name: 'Error', message: 'String you pass in the constructor' }

The throw someObject will throw the object as is and will not allow any further code execution from the try block, ie same as throw new Error.

Here is a good explanation about The Error object and throwing your own errors

The Error Object

Just what we can extract from it in an event of an error? The Error object in all browsers support the following two properties:

• name: The name of the error, or more specifically, the name of the constructor function the error belongs to.

• message: A description of the error, with this description varying depending on the browser.

Six possible values can be returned by the name property, which as mentioned correspond to the names of the error's constructors. They are:

Error Name          Description

EvalError           An error in the eval() function has occurred.

RangeError          Out of range number value has occurred.

ReferenceError      An illegal reference has occurred.

SyntaxError         A syntax error within code inside the eval() function has occurred.
                    All other syntax errors are not caught by try/catch/finally, and will
                    trigger the default browser error message associated with the error. 
                    To catch actual syntax errors, you may use the onerror event.

TypeError           An error in the expected variable type has occurred.

URIError            An error when encoding or decoding the URI has occurred 
                   (ie: when calling encodeURI()).

Throwing your own errors (exceptions)

Instead of waiting for one of the 6 types of errors to occur before control is automatically transferred from the try block to the catch block, you can also explicitly throw your own exceptions to force that to happen on demand. This is great for creating your own definitions of what an error is and when control should be transferred to catch.

Logography

Does not even answer the question yet the most upvoted answer? – Slype

@Slype User ho asked question was looking for detailed understanding as per chat at that time, so accordingly answer has been provided and useful to the user. that is the reason for accepted and most up votes. – Logography

@HemantMetalia But he's right, the answer shows not even the slightest attempt to answer OPs question as stated. If some very different answer in chat was answered that should remain in chat, here question and answer have no logical connection whatsoever. – Ostensible

And to answer the original question, it does not matter to Javascript. However, Error (and subclasses) are used by convention. They also by default provide a stack property, although that could manually be added to any other. So it's really mostly convention, program flow is not impacted by what you throw, just that you throw at all matters. You could throw "grandmother down the stairs"; and it would work the same, except that there won't be an attached stack trace and error handling functions, reporters, debuggers expect Error, or the properties that comes with, to be more precise. – Ostensible

What if the Error object is passed up to another promise with its own catch block? Would you once again throw a new Error object or just throw the returned object which is already an Error. – Sedgewinn

Answer 2

throw "I'm Evil"

throw will terminate the further execution & expose message string on catch the error.

try {
  throw "I'm Evil"
  console.log("You'll never reach to me", 123465)
} catch (e) {
  console.log(e); // I'm Evil
}

Console after throw will never be reached cause of termination.

---

throw new Error("I'm Evil")

throw new Error exposes an error event with two params name & message. It also terminate further execution

try {
  throw new Error("I'm Evil")
  console.log("You'll never reach to me", 123465)
} catch (e) {
  console.log(e.name, e.message); // Error I'm Evil
}

throw Error("I'm Evil")

And just for completeness, this works also, though is not technically the correct way to do it -

try {
  throw Error("I'm Evil")
  console.log("You'll never reach to me", 123465)
} catch (e) {
  console.log(e.name, e.message); // Error I'm Evil
}

console.log(typeof(new Error("hello"))) // object
console.log(typeof(Error)) // function

Bret

what about the diff between "throw Error('whatever')" and "throw new Error('whatever')" - both work. – Bosquet

Error is functional, new Error is a constructor. both works same developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/… – Bret

@Mörre See this section Used as a function from this link... developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/… – Bret

Okay, I got it. It's a function. – Bret

@Mörre what are you talking about?? Both of those quotes, "throw Error is functional" and "throw new Error is a constructor" is both factually accurate and makes clear sense. That is literally the only relevant difference between the two. throw just throws something, it doesn't care what, could be a string, an object, an instance of a class (new Something()). This answer got a lot of upvotes because it's the only correct answer. – Luminesce

@Bret your comments were really clear and useful to me. I will only point out the obvious: the mozilla team updated that page and the anchor #Used_as_a_function doesn't work anymore. – Flowerer

console.error(e) – Wan

Answer 3

The following article perhaps goes into some more detail as to which is a better choice; throw 'An error' or throw new Error('An error'):

http://www.nczonline.net/blog/2009/03/10/the-art-of-throwing-javascript-errors-part-2/

It suggests that the latter (new Error()) is more reliable, since browsers like Internet Explorer and Safari (unsure of versions) don't correctly report the message when using the former.

Doing so will cause an error to be thrown, but not all browsers respond the way you’d expect. Firefox, Opera, and Chrome each display an “uncaught exception” message and then include the message string. Safari and Internet Explorer simply throw an “uncaught exception” error and don’t provide the message string at all. Clearly, this is suboptimal from a debugging point of view.

Zipper

And what if I'm writing code in ExpressJS for a REST API, this issue with browsers would not exist anymore. Is it nevertheless preferable to use throw new Error() ? – Eratosthenes

Answer 4

TLDR: they are equivalent Error(x) === new Error(x).

// this:
const x = Error('I was created using a function call!');
​​​​// has the same functionality as this:
const y = new Error('I was constructed via the "new" keyword!');

source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error

throw and throw Error are functionally equivalent. But when you catch them and serialize them to console.log they are not serialized exactly the same way:

throw 'Parameter is not a number!';
throw new Error('Parameter is not a number!');
throw Error('Parameter is not a number!');

Console.log(e) of the above will produce 2 different results:

Parameter is not a number!
Error: Parameter is not a number!
Error: Parameter is not a number!

Krimmer

What about this : throw 'message' is it the same ? – Coreencorel

"throw and throw Error will are functionally equivalent" – not really. One throws a string, which things like Bugsnag will complain about because it can't get a stacktrace from them. Do you mean functionally as in it'll stop the code running, or that it'll throw something? Either way they're semantically different? – Cranny

Answer 5

You first mention this code:

throw new Error('sample')

and then in your first example you write:

throw new Error({'hehe':'haha'}) 

The first Error object would actually be useful, because it is expecting a string value, in this case 'sample'. The second would not because you are trying to pass an object in, and it is expecting a string, and would not display a helpful error.

The error object would have the "message" property, which would be 'sample'.

Spank

The second one does work, just not in a very useful way. It executes the toString() method on the object passed in, resulting in [object Object] in the error (as the Op wrote). – Fletafletch

Answer 6

The Error constructor is used to create an error object. Error objects are thrown when runtime errors occur. The Error object can also be used as a base object for user-defined exceptions.

User-defined Errors are thrown via the throw statement. program control will be passed to the first catch block in the call stack.

The difference between throwing an error with and without Error object:

---

throw {'hehe':'haha'};

In chrome devtools looks like this:

Chrome tells us that we have an uncaught error which just is a JS object. The object itself could have information regarding the error but we still don't know immediately where it came from. Not very useful when we are working on our code and debugging it.

---

throw new Error({'hehe':'haha'}); 

In chrome devtools looks like this:

An error thrown with the Error object gives us a stack trace when we expand it. This gives us valuable information where the error precisely came from which is often valuable information when debugging your code. Further note that the error says [object Object], this is because the Error constructor expects a message string as a first argument. When it receives a object it will coerce it into a string.

Plasty

this answer makes the most sense – Sunlight

Answer 7

you can throw as object

throw ({message: 'This Failed'})

then for example in your try/catch

try {
//
} catch(e) {
    console.log(e); //{message: 'This Failed'}
    console.log(e.message); //This Failed
}

or just throw a string error

throw ('Your error')

try {
//
} catch(e) {
    console.log(e); //Your error
}

throw new Error //only accept a string

As

Answer 8

TLDR

throw new Error('problem') captures a number of properties of the place where the error happened.

throw 'problem' does not

new Error('message') captures the execution stack + others

Using an Error object allows you to capture the execution stack at the point where you throw the error. So when the error gets passed up the error handling tree, so does this stack snapshot.

So inserting throw "test error" somewhere in my codebase results in:

Whereas throw new Error('test error') results in:

You can see that the native Error object captures the stack at the point I throw the error and makes it available to whatever captures the error. That makes it easier for me to trace the problem when I'm debugging it.

In addition to that it also captures properties such as fileName, lineNumber and columnNumber.

If you use the stack trace it's there for exception trackers to log for you

In this case the stack is being printed into the browser console but if you're using Javascript error logging tools like Appsignal or Bugsnag then that stack will also be available in them too. If you inspect the error object you can access the stack snapshot directly:

err = new Error('test')
err.stack

The heuristic I use for deciding which format to use

When I don't plan to catch the exception I use new Error('problem')

When I'm throwing an error because something unexpected or out-of-bounds has happened in the application, let's say the local datastore is corrupted, I might be in a situation where I don't want to handle it, but I do want to flag it. In this case I'll use the Error object so I have that stack snapshot.

By using throw new Error('Datastore is corrupted') it's easier to trace my way back to what's happened.

When I plan to catch the exception I use throw 'problem'

Edit - on re-reading this I think the next part needs some caution. It's generally a good idea to be very specific about which error you choose to catch otherwise you can end up catching things that you really wanted to bubble all the way up. In general it's probably better to create a specific error type and catch that specific error (or message string). This allows errors you didn't anticipate to bubble up to the surface."

If the error is an expected error that I plan to catch and handle then I'm not going to get much use out of the stack snapshot.

So, let's say I use an http service and it returns a 500 HTTP code. I may treat this as an error which I throw "responseCode=500" and then subsequently catch and handle.

Unpredictable

Answer 9

The Error class includes debugging information, such as the error's call stack, as properties of its instances. JS interpreters know how to serialise Error instances into an informative error message string, and their structure can also be consumed by debugging software - such as browser dev tools - to construct a more informative GUI representation of the error. This is why it's generally more useful to throw an instance of the Error class rather than simply throwing, for example, a string describing the error, or a number representing an error code.

Using custom errors

It's particularly useful to make your own subclasses of Error, which allow you to uniquely identify different types of error with a descriptive name and machine-readable...

• clues for debugging,
• information for better user-facing error messages, or
• information to help recover from the error.

Then, when you're handling errors, you can use the nice and clean instanceof operator to check what kind of error occurred. e.g.:

class DangerousWaterCurrent extends Error {
    constructor(waterSpeed){
        super(`These waters are moving at ${waterSpeed} metres per second - too fast to cross!`) // Provide a `message` argument to the Error() constructor
        this.waterSpeed = waterSpeed // This passes some context about why/how the error occurred back to whichever function is going to catch & handle it
    }
}

// ...later...

try {
    swimAcrossRiver(river)
} catch (thrownValue) {
    if (thrownValue instanceof DangerousWaterCurrent) {
        if (thrownValue.waterSpeed <= 3){ 
            paddleKayak(river)
        } else {
            constructBridge(river)
        }
    } else {
        throw thrownValue // "Re-throw" the error back up the execution chain, for someone else to handle
    }
}

---

new Error() vs Error()

There is a "convenient" shorthand way to make an instance of Error: by calling Error(message), instead of new Error(message), the way you'd make an instance of a normal class. This is a deliberate exception, inserted by the language designers, to the rule. There are similar shorthands for other in-language classes, like Number() and String(). They also let you call these classes with () as if they were functions, not classes. JS doesn't allow normal classes to do this, even though they're all actually functions under the syntactical sugar of "classes". Try in a REPL:

> class E extends Error {}
> Error(); "a value"
"a value"
> E(); "a value"
Uncaught TypeError: Class constructor E cannot be invoked without 'new'
    at <anonymous>:2:1

A broader opinion on design: Personally, I think this design decision was a mistake, as it adds more exceptions to the rules of JavaScript - which means more to learn for programmers, and more for language translators/interpreters to account for. Instead of C++/Java's new keyword, simply calling a class as if it were a function (as in Number("abc123")) should have the properties that the new keyword currently has: the class's constructor function should be executed. Inside that function, this should be bound to the instance and then returned implicitly. The new keyword could then be discarded from the language. This is how Python's syntax works, and it's simpler, more readable, and more convenient.

Maley

This is the only answer that covers the difference between the new Error and Error sufficiently 👍🏻 – Mattos

Answer 10

React behavior

Apart from the rest of the answers, I would like to show one difference in React.

If I throw a new Error() and I am in development mode, I will get an error screen and a console log. If I throw a string literal, I will only see it in the console and possibly miss it, if I am not watching the console log.

Example

Throwing an error logs into the console and shows an error screen while in development mode (the screen won't be visible in production).

throw new Error("The application could not authenticate.");

Whereas the following code only logs into the console:

throw "The application could not authenticate.";

Dishtowel

Answer 11

throw something works with both object and strings.But it is less supported than the other method.throw new Error("") Will only work with strings and turns objects into useless [Object obj] in the catch block.

Sigurd

Answer 12

This is quite old but hopefully, anyone searching this can still learn from this:

First and famous, in javascript, we have something called Primitive Wrapper; a primitive wrapper takes primitive data and represents it in an object format by simply using the "constructor pattern". Still yet, in primitive wrappers, you can decide to have your data returned as an object type or you can have it returned as its primitive type(in this situation, you are now given a go-ahead command for javascript to extract the primitive value and in this case, you don't use the new keyword).

In Summary:

1. throw "My error": this creates an Error object and returns the primitive data extracted from the constructor "this" object. And if you try checking the typeof in the catch block, it tells you its a primitive typeof "string"

2. throw new Error("My error"): this returns you an object where you can access the error value from the message property. What simply happens here is that the "new keyword" constructs a "this" object and assign "{name:"Error",message:"..."}" to it and returns it. And when you try to check the typeof from the catch block, you will see a typeof "object".

Note: in a situation where you explicitly pass in a custom object to the throw, it will behave as if you invoked the constructor using the new keyword and therefore, the catch block will return you the custom object and not the message property value. For example: throw {name:"RangeError",message:"range is out of scope",environment:"Happened in testing function"}.

In conclusion, use whatever suits you ones you know what you are doing. But for me if i don't need much data but rather just the error, then I go for Primitive returner.

Cup

Answer 13

throw new Error() is good for throwing a specified error. But if you want to do custom error handling, it's better to use throw { example: 'error' } .

That is, if you want to know the specified error, use throw new Error("example string") , if you want to handle the error in custom, use throw.

function makeErrorResponse(err = {}, httpStatus, status, message, message) {
    const error = new Error();

    error.httpStatus = httpStatus;
    error.status = status;
    error.message = message;
    error.err = err;

    return error;
  }

throw makeErrorResponse({}, 500, 500, 'server error');

Pectoralis

Throwing something that isn't instanceof Error isn't a great idea and complicates the rest of the code because now you can't rely on the normal error properties being available, also you can't trace your error back to its source because it has no stack. While the second example is okay, it's better to use custom errors that inherit from Error. You can then easily extend from those for more levels of granularity, and use instanceof to check for errors (either a specific one or a class of errors) easily. – Whisky

I use custom errors by inheriting errors for network errors like api errors, db errors. As you said, custom errors are useful when debugging. However, if there is no file necessary to start the server or a port conflict error occurs, I think it is right to stop the server with its own error rather than a custom error. – Pectoralis

Answer 14

The Error constructor basically does something like this:

Error (message) {
  if(!this instanceof Error)
    return new Error(message);
  ...
}

If a constructor is called with new, it gets the pointer of the newly created object as its this pointer. If it is called as a function, this is set to windows.

However, it isn't as easy as it should to implement your own error types. Since you don't want your constructor being in the stacktrace, you'll need to call Error.captureStackTrace(this, MyErrorConstructor); in your constructor function, This will eliminate the constructor from the stack trace.

However, if you want to use above trick (new vs. function call) in your Subclass, it WILL show your constructor in the stack trace (as it appears twice on the stack). Handling this is quite tricky. You can instantiate a new Error and, replace its prototype with your subclass prototype or you can create a subclass of your Error, so the nested constructor of this sub-subclass is different and can be eliminated by captureStackTrace.

Coss