Muss async/await Try Catch hinzufügen?

        Beim Schreiben asynchroner Funktionen sind sowohl Promise- als auch Async-Lösungen sehr verbreitet. Selbst im selben Projekt verwenden verschiedene Entwickler unterschiedliche Gewohnheiten. Der Vergleich zwischen den beiden steht jedoch nicht im Mittelpunkt dieses Artikels. Er kann nur in einem Satz zusammengefasst werden: „Async ist die ultimative Lösung für die asynchrone Programmierung.“

        Bei Verwendung der Async-Funktion wird in vielen Artikeln die Verwendung von Try Catch zum Abfangen von Ausnahmen empfohlen. Tatsächlich habe ich jedoch die Codes vieler Projekte gelesen und die Codes werden nicht strikt befolgt. Viele von ihnen sind nutzlos, und selbst die Catch-Funktion ist es nicht geschrieben. Warum ist das so? Wolltuch?

Schauen wir uns zunächst das Codebeispiel für den Fall der Verwendung von Try Catch an:

Beispiel 1: Try Catch verwenden

function getUserInfo () {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
                reject('请求异常')
        }, 1000)
    })
}

async function logined () {
    try {
        let userInfo = await getUserInfo()
        // 执行中断
        let pageInfo = await getPageInfo(userInfo?.userId)
    } catch(e) {
        console.warn(e)
    }
}

logined()

         Nach der Ausführung wird es im Catch erfasst  请求异常, und dann unterbricht die Funktion getUserInfo die Ausführung, was logisch ist. Bei Schnittstellen mit Abhängigkeiten kann das Unterbrechen der Ausführung Programmabstürze vermeiden. Das einzige Problem hierbei ist, dass der Try-Catch zu belegen scheint Zu viele Zeilen. Wenn es ein wenig überflüssig erscheint, jede Schnittstelle zu schreiben.

Beispiel 2: Direktfang

        Da unter normalen Umständen await auf den Befehl ein Promise-Objekt folgt, kann sich der obige Code natürlich eine Optimierungslösung vorstellen:

function getUserInfo () {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
                reject('请求异常')
        }, 1000)
    })
}

async function logined () {
    let userInfo = await getUserInfo().catch(e => console.warn(e))
    // 执行没有中断，userInfo 为 undefined
    if (!userInfo) return // 需要做非空校验
    let pageInfo = await getPageInfo(userInfo?.userId)
}

logined()

           Nach der Ausführung kann der Catch die Ausnahme normal abfangen, aber das Programm wird nicht unterbrochen und der userInfo Rückgabewert  undefinedWenn es also so geschrieben wird, muss der Rückgabewert auf Nicht-Nullheit überprüft werden.  if (!userInfo) return Ich denke, das ist ein Bit-Gegenlogik, und die Ausführung sollte unterbrochen werden, wenn eine Ausnahme auftritt;

Anregung

        Es besteht keine Notwendigkeit zu unterbrechen, wenn das Warten abnormal ist. Sie können es so schreiben, Sie müssen eine Nicht-Null-Prüfung durchführen und die Konsole meldet keine Fehlermeldung

let userInfo = await getUserInfo().catch(e => console.warn(e))
if (!userInfo) return

         Sie müssen unterbrechen, wenn das Warten abnormal ist, und sich um Konsolenfehler kümmern. Sie können so schreiben

try {
    let userInfo = await getUserInfo()
    // 执行中断
    let pageInfo = await getPageInfo(userInfo?.userId)
} catch(e) {
    console.warn(e)
}

         Wenn Sie unterbrechen müssen, wenn das Warten abnormal ist, Sie sich aber nicht um den Konsolenfehler kümmern, können Sie so schreiben

let userInfo = await getUserInfo().catch(e => {
    console.warn(e)
    return Promise.reject(e) // 会导致控制台出现 uncaught (in promise) 报错信息
})
// 执行中断
let pageInfo = await getPageInfo(userInfo?.userId)

Zusammenfassen:

Mehrere Schreibweisen: Auf den ersten Blick denken Sie vielleicht, dass die dritte Schreibweise von Catch die beste ist, aber nachdem ich darüber nachgedacht habe, denke ich, dass Try Catch aus Sicht der Benutzererfahrung die beste, logische und intuitivste ist Beim synchronen Programmierdenken wird auf der Konsole keine uncaught (in promise) Fehlermeldung .

Der Catch (im Inneren ablehnen) des Kettenaufrufs ist die Callback-Schreibmethode des traditionellen Versprechens. Da die synchrone Programmiermethode von Async Wait verwendet wurde, erscheint es unnötig, die Catch-Chain-Schreibmethode zu verwenden.