There are no error when you're using reject function along with throw statement

[dSalieri]

https://html.spec.whatwg.org/multipage/webappapis.html#hostenqueuepromisejob

If result is an abrupt completion, then report the exception given by result.[[Value]].

But there is one case that won't perform this step:

new Promise((resolve, reject) => {
  reject(new Error("reject error"));
  console.log("message after rejection");
  throw Error("throw error");
  console.log("message that won't be printed")
})

I've tested this example in last chrome and firefox and no one of them did not print in the console "throw error". I don't understand this, this is definitely abrupt completion but there is not error message. What's the matter?

[Kaiido]

new Promise(executor) doesn't call HostEnqueuePromiseJob (executor isn't pushed in a microtask).
As for why it doesn't report the exception in that case, it's because the 10th step of the linked algo does ask to call reject instead, but since reject already has been called, it's does nothing.

[dSalieri]

@Kaiido At some time I decided simplify my example and I used just a Promise without anything. But okay here you're right.

Well in that case look at this example:

new Promise((resolve) => {
    resolve({then: function(res, rej){
        rej(new Error("reject error"));
        console.log("message after rejection");
        throw Error("throw error");
        console.log("message that won't be printed");
    }})
});

What correspond to NewPromiseResolveThenableJob:

1. Let job be a new Job Abstract Closure with no parameters that captures promiseToResolve, thenable, and then and performs the following steps when called:
  a. Let resolvingFunctions be CreateResolvingFunctions(promiseToResolve).
  b. Let thenCallResult be Completion(HostCallJobCallback(then, thenable, « resolvingFunctions.[[Resolve]], resolvingFunctions.[[Reject]] »)).
  c. If thenCallResult is an abrupt completion, then
    i. Return ? Call(resolvingFunctions.[[Reject]], undefined, « thenCallResult.[[Value]] »).
  d. Return ? thenCallResult.

There is no case for step d that it would be an abrupt completion; my example it's step i. Result of it gets to HostEnqueuePromiseJob in step 3

Let result be job()

that should be checked in step 5

If result is an abrupt completion, then report the exception given by result.[[Value]].

Here I don't get an error because it is not abrupt completion. Which of example here will be for step above with abrupt completion. Now I think that step 5 is unreachable by that algoritm and I think that ECMAScript should correct its spec.