In some browsers, using the native Error class enables cool features like automatic stack trace.

Just in case you need special kind of Error (ie: subclasses), I recommend doing it that way:

  function SomeError(message) {
   
   // the real instance should be an Error:
   var self = new Error(message);
   
   // but the prototype could be updated
   if(self.__proto__) { self.__proto__ = SomeError.protoype }
   else { copyProperties(SomeError.prototype, self); }
   
   // do some more custom things
   // ...
   
   // return the instance
   return self;
   
  }
  
  SomeError.prototype = Object.create(Error.prototype);
  
  throw new SomeError('abc');





----------------------------------------
> From: jonas at sicking.cc
> Date: Wed, 10 Jul 2013 12:23:54 -0400
> Subject: Creating your own errors
> To: es-discuss at mozilla.org
>
> Hi all,
>
> What is the current expected way for an author to throw a custom
> errors? You obviously could do something like:
>
> throw { reason: "TimeoutError" };
> or
> throw "TimeoutError";
>
> However that makes it very hard for anyone receiving an exception to
> inspect what it is. I.e. you'd first have to check what type of value
> it is, i.e. if it's a string, something that's instanceof Error, or
> something with just custom properties.
>
> Instead you can do
>
> throw new Error;
>
> However, as I understand it, that doesn't let you pass
> machine-readable information in the error. You can only pass a message
> which is intended for human consumption. I.e. something like:
>
> throw new Error("operation took too long and timed out.");
>
> Yet another alternative is to do
>
> let e = new Error;
> e.name = "TimeoutError";
> throw e;
>
> This is a little bit more code than expected though.
>
> A shorter alternative that is somewhat compatible with Error is
>
> throw { name: "TimeoutError" };
>
> However this means that 'instanceof Error' returns false, which could
> mean that code is forced to check which properties are set.
>
> The reason I'm asking is that the DOM has invented a completely new
> interface, DOMError. This seems pretty heavy-handed and yet another
> instance of the DOM doing it in its own way rather than using existing
> ES functionality.
>
> I'd like for the DOM to mimic what we expect authors to do. It's just
> not obvious to me what authors are expected to do if they want to
> throw a machine readable error. I.e. one that allows code to catch the
> error and handle it.
>
> / Jonas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

In some browsers, using the native `Error` class enables cool features like automatic stack trace.

Just in case you need special kind of `Error` (ie: subclasses), I recommend doing it that way:

```js
function SomeError(message) {

    // the real instance should be an Error:
    var self = new Error(message);

    // but the prototype could be updated
    if(self.__proto__) { self.__proto__ = SomeError.protoype }
    else { copyProperties(SomeError.prototype, self); }

    // do some more custom things
    // ...

    // return the instance
    return self;

}

SomeError.prototype = Object.create(Error.prototype);

throw new SomeError('abc');
```