ParseError doesn't inherit from Error

[romanbsd]

It has these implications:

1. There's no stack trace
2. e = new ParseError(); e instanceof Error === false
   We noticed this while using Sentry's raven for error reporting.

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

[romanbsd]

however, I'm not sure how to do this is in ES6, as with this code e instanceof ParseError === false:

export default class ParseError extends Error {
  constructor(code, message) {
    super();
    this.code = code;
    this.message = message;
  }
}

[andrewimm]

This is intentional -- A ParseError is not meant to be thrown. It reflects a canonical representation of a difficulty communicating with the server. In early versions of the SDK (before Promises, and certainly before the Promises/A+ spec was written to handle Errors), the object was passed to error callbacks and handled within those.

Since then the specs have changed, such that passing an object to the reject() call of a Promise is the same as throwing it. It might be viable to now make ParseError inherit from Error, but I would consider this a breaking change and not take it lightly.

[andrewimm]

Also, a stack trace does not seem helpful. Parse Errors are generated as the response from the server, so they will always trace back to the REST controller, through a confusing, likely-illegible mess of Promise resolutions. Due to the way Promises are resolved through micro-tasks, any exceptions probably won't point back to the code that actually generated them; they create new execution contexts. If you want to get useful error reporting from Parse Errors, you'd need to write some custom code anyways.

Regardless of how developers handle errors, I always highly recommend that any Promise chain ends with a .catch((error) => { ... }) block that can pass location-specific metadata to a global error handler. That way, you can fork based on the error passed in (is it a ParseError, or a genuine execution Error?) and attach any other useful info before processing it.

[dplewis]

Closing via #658