This was originally motivated by one of the lints fixed in #278:
src/services/keystore.ts
Line 619:6: Expected an error object to be thrown no-throw-literal
Line 621:6: Expected an error object to be thrown no-throw-literal
Line 626:4: Expected an error object to be thrown no-throw-literal
Line 630:3: Expected an error object to be thrown no-throw-literal
I resolved this at the time by using Promise.reject instead of throw, because TypeScript is currently configured to output ES2016 code which does not have the cause argument in the Error constructor. But as explained in the ESLint docs for no-throw-literal:
It is considered good practice to only throw the Error object itself or an object using the Error object as base objects for user-defined exceptions. The fundamental benefit of Error objects is that they automatically keep track of where they were built and originated.
This was originally motivated by one of the lints fixed in #278:
I resolved this at the time by using
Promise.reject
instead ofthrow
, because TypeScript is currently configured to output ES2016 code which does not have thecause
argument in theError
constructor. But as explained in the ESLint docs for no-throw-literal: