Dokumentation Commerce Implementierungs-Playbook

Best Practices für die Ausnahmebehandlung

Letzte Aktualisierung: 30. Dezember 2024

Themen:
Best Practices

Erstellt für:

Experte
Entwickler

Wenn eine Ausnahme nicht in die exception.log geschrieben wird, wobei das Ausnahmemodell als Kontext dient, wird sie in New Relic oder einem anderen PSR-3 Monolog-kompatiblen Protokollspeicher nicht korrekt erkannt und analysiert. Wenn Sie nur einen Teil der Ausnahme protokollieren (oder sie in der falschen Datei protokollieren), führt dies zu Fehlern in der Produktion, wenn Ausnahmen übersehen werden.

Korrekte Ausnahmebehandlung

Die folgende Checkliste enthält Beispiele zur Veranschaulichung der korrekten Ausnahmebehandlung.

Schreiben in das Ausnahmenprotokoll

Schreiben Sie unabhängig von weiteren Aktionen unter Verwendung des folgenden Musters in das Ausnahmenprotokoll, es sei denn, es gibt einen zwingenden Grund, dies nicht zu tun.

try {
    $this->productRepository->getById($sku);
} catch (Exception $e) {
    $this->logger->critical($e);
}

Bei diesem Ansatz werden die $e->getMessage zur Protokollmeldung und das $e gemäß dem PSR-3-Kontextstandard) automatisch im Kontext. Dies geschieht in \Magento\Framework\Logger\Monolog::addRecord.

Stummschaltung

Stummschalten von Signalen durch Nichtprotokollieren von Ausnahmen, die Teil des beabsichtigten Betriebsablaufs sind. Wenn eine Ausnahme auftritt, sind keine Folgemaßnahmen erforderlich, sodass sie nicht protokolliert und analysiert werden muss, wenn sie auftritt. Fügen Sie einen Kommentar hinzu, der den Grund für die Stummschaltung der Signale angibt und angibt, dass dies beabsichtigt ist. Kombinieren mit phpcs:ignore.

try {
    $this->productRepository->deleteById($sku);
} catch (NoSuchEntityException $e) { // phpcs:ignore Magento2.CodeAnalysis.EmptyBlock.DetectedCatch
    // Product already removed
}

Ausnahmen beim Downgrade

Downgrade-Ausnahmen nach dem PSR-3-.

try {
    $this->productRepository->getById($sku);
} catch (Exception $e) {
    $this->logger->debug($e->getMessage(), ['exception' => $e]);
}

Die Protokollierung kommt immer zuerst

Als Best Practice wird die Protokollierung immer zuerst im Code angezeigt, um zu verhindern, dass eine weitere Ausnahme oder ein schwerwiegender Fehler ausgelöst wird, bevor in das Protokoll geschrieben wird.

try {
    $this->productRepository->getById($sku);
} catch (Exception $e) {
    $this->logger->critical($e);
    $this->alternativeProcedure();
}

Protokollmeldungen und die gesamte Ausnahmenverfolgung

Protokollmeldungen und die gesamte Ausnahmenablaufverfolgung gemäß dem PSR-3-.

try {
    $this->productRepository->getById($sku);
} catch (Exception $e) {
    $this->logger->critical($e->getMessage(), ['exception' => $e, 'trace' => $e->getTrace()]);
}

Falsche Ausnahmebehandlung

Die folgenden Beispiele zeigen eine falsche Ausnahmebehandlung.

Logik vor der Protokollierung

Die Logik vor der Protokollierung kann zu einer weiteren Ausnahme oder einem schwerwiegenden Fehler führen. Dies verhindert, dass die Ausnahme protokolliert wird, und sollte durch richtiges Beispiel“werden.

try {
    $this->productRepository->deleteById($sku);
} catch (NoSuchEntityException $e) {
    $this->alternativeProcedure();
    $this->logger->critical($e);
}

Leere `catch`

Leere catch können ein Zeichen für eine unbeabsichtigte Stummschaltung sein und sollten durch das richtige ersetzt.

try {
    $this->productRepository->deleteById($sku);
} catch (NoSuchEntityException $e) {
}

Doppelte Lokalisierung

Wenn die erfasste lokalisierte Ausnahme noch nicht übersetzt wurde, beheben Sie das Problem an der Stelle, an der die Ausnahme zum ersten Mal ausgelöst wurde.

try {
    $this->productRepository->getById($sku);
} catch (LocalizedException $e) {
    throw new LocalizedException(__($e->getMessage()));
}

Protokollmeldungen und Verfolgung zu verschiedenen Protokolldateien

Der folgende Code protokolliert den Stacktrace für eine Ausnahme fälschlicherweise als Zeichenfolge in einer Protokolldatei.

try {
    $this->productRepository->getById($sku);
} catch (\Exception $e) {
    $this->logger->error($e->getMessage());
    $this->logger->debug($e->getTraceAsString());
}

Dieser Ansatz führt zu Zeilenumbrüchen in der Nachricht, die nicht mit PSR-3 konform sind. Die Ausnahme, einschließlich Stacktrace, muss Teil des Nachrichtenkontexts sein, um sicherzustellen, dass sie korrekt mit der Nachricht in New Relic oder einem anderen PSR-3 Monolog-kompatiblen Protokollspeicher gespeichert wird.

Beheben Sie dieses Problem, indem Sie den Code durch die richtigen Beispiele ersetzen, die unter Schreiben in das Ausnahmenprotokoll oder Downgrade-Ausnahmen zu sehen sind.

Ausnahmen ohne Kontext herunterstufen

Die Ausnahme wird zu einem Fehler heruntergestuft, wodurch nicht die Übergabe eines -Objekts, sondern nur einer Zeichenfolge ermöglicht wird. Daher die getMessage(). Dadurch geht die Ablaufverfolgung verloren und sollte durch die richtigen Beispiele ersetzt werden, die unter Schreiben in das Ausnahmenprotokoll oder Downgrade-Ausnahmen zu sehen sind.

try {
    $this->productRepository->getById($sku);
} catch (\Exception $e) {
    $this->logger->error($e->getMessage());
}

Nur die Nachricht im Ausnahmenprotokoll protokollieren

Anstatt das -Objekt $e zu übergeben, wird nur $e->getMessage() übergeben. Dadurch geht die Ablaufverfolgung verloren und sollte durch die richtigen Beispiele ersetzt werden, die gezeigt werden Schreiben in das Ausnahmenprotokoll oder Downgrade-Ausnahmen.

try {
    $this->productRepository->getById($sku);
} catch (\Exception $e) {
    $this->logger->critical($e->getMessage());
}

Fehlende `// phpcs:ignore Magento2.CodeAnalysis.EmptyBlock.DetectedCatch`

Das Auslassen der phpcs:ignore-Trigger ist ein Warnhinweis in PHPCS und sollte nicht Ihren CI übergeben. Dies sollte durch das richtige Beispiel ersetzt werden, das unter Stummschaltungssignale“ist.

try {
    $this->productRepository->deleteById($sku);
} catch (NoSuchEntityException $e) {
    // Product already removed
}

recommendation-more-help