Promise fails to catch

I'm trying to understand error catching in promises and I'm not getting something. I've read up on it and from everything I've seen it should be working so I'm not sure what I'm missing. I have a sample method that for now I'm just throwing an error (to simulate when it may actually throw an error later). That method looks like this:

DeleteProject(id: string, customerId: string): Promise<void> {
    throw new Error('test error');
}

I'm then calling this in my code like this:

projectService.DeleteProject(state.FocusedProject.ID, state.FocusedProject.CustomerID)
    .then(() => {
        ...stuff when it works...
    })
    .catch(error => {
        console.log('caught you');
        HandleError(error, 'Delete Project');
    });

When this method does not throw an error the code in the then block gets called and all works fine. However, when I throw the error it gives me an unhandled execution error and the catch block is never called.

From everything I've read, throwing an error inside of that function should automatically be caught and return the rejected promise right? If so then when is it not being caught?

I'm sure I'm missing something here but I can't see what it is. I basically want the catch block to say 'if anything goes wrong in the method I called then do this'.

As in the comments, DeleteProject is marked as returning a Promise<void> but it is not marked async. Like all non-async functions, it can throw errors, which are then caught as part of a try/catch block instead of a call to Promise.then or Promise.catch. These are two separate error channels that have to be handled separately.

Promise machinery will convert errors thrown with throw into rejected Promises, but only in these situations:

1. In a [new Promise constructor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/Promise#parameters "Any errors thrown in the executor will cause the promise to be rejected")
2. In a function passed to [Promise.then or Promise.catch](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/then#return_value "throws an error: p gets rejected with the thrown error as its value")
3. In an [async function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function#return_value "A Promise which will be resolved [...], or rejected with an exception thrown from, or uncaught within, the async function")

Unless there's real value in handling the error synchronously, it might be better to use the return Promise.reject(new Error(...)) style here instead of throw new Error(...). It is atypical to require function caller to handle both styles of error (synchronous and asynchronous), and presumably it is possible for DeleteProject to return an error asynchronously if it communicates with the server. This would mean that callers only have one error channel to handle regardless of whether the error is synchronous or asynchronous.

In a follow-up comment from the OP (sfaust), they suggest that they will need to handle both types (asynchronous from the server, and synchronous from invalid input). Distinguishing between development-time error and runtime errors is a rational reason, but if so it may be very important to document the fact that the function (DeleteProject here) can issue both types of error. Remember, though, that even when errors can be detected or caught synchronously, it's still up to you what kind of external API you provide to callers of your function: For manually-written promise-returning functions (i.e. without async), it may still be more predictable to send all errors through a rejected promise, even if it means wrapping the function in a try/catch block and using a particular subclass of Error to indicate invalid calls to the function.