为什么我在repl.it上看到此代码中的“Promise {<pending>}”？

Question

I know this question has been asked a lot on stackoverflow and I've searched a lot and still am not able to understand.

 async function testFunc() { var test = await getSomething(); //test.resolve(); console.log("hello" + test); return ""; } testFunc().then(token => {}).catch(x => {}); function getSomething() { return "ex"; } 

In most answers it is suggested to use .then() to resolve the promise, but I've done that and I still get promise pending. What is wrong in this ?

Tested this on https://repl.it/repls/UntrueLankySorting

It shows me this:

helloex
=> Promise { <pending> }

Answer 1

Tested this on https://repl.it/repls/UntrueLankySorting

It's showing you the result of the call to catch here:

 testFunc().then(token => {}).catch(x => {}); 

You don't care about that promise, it's just that that environment shows it to you. It is indeed a pending promise as of when catch returns, but it gets settled later.

That's just an aspect of the environment you were running it in. The code itself is fine other than the issue I mentioned in comments (that getSomething doesn't return a promise, so there's no need to await it).

In a comment you've asked:

Would catch return in this case? Since no error is thrown it should resolve at then right?

then and catch always return a promise. The promise they return gets resolved or rejected depending on what happens to the promise you called then / catch on and, if their handler gets run, what happens in the handler and what it returns.

In this example, here's what that code does:

1. Calls testFunc and gets the promise it returns ( async functions always return promises). Call that Promise A.
2. Calls then on Promise A. then returns a new promise (Promise B).
3. Calls catch on Promise B. catch returns a new promise (Promise C).
4. repl.it shows you Promise C, which is pending at that point.¹
5. Promise A fulfills², which calls the then handler. The then handler (effectively) returns undefined .
6. That fulfills Promise B with the value undefined , which fulfills Promise C (without calling the catch handler, because the promise was fulfilled, not rejected).

---

¹ It would be permissible for an implementation to show a fulfilled state there instead in this example , but for all intents and purposes, it's best to think of the promise as pending at that point. Since code can never directly observe the state of a promise, your code can't tell the difference.

² Similarly, it would be permissible if it were already fulfilled before then was called on it, but similarly you can never see that directly in code, so...