Best practice per la gestione delle eccezioni

Se un'eccezione non viene scritta nel file exception.log con il modello di eccezione come contesto, non viene riconosciuta e analizzata correttamente in New Relic o in un altro archivio di log compatibile con il monologo PSR-3. La registrazione solo di una parte dell’eccezione (o la registrazione nel file errato) causa bug nella produzione quando le eccezioni vengono ignorate.

Gestione delle eccezioni corretta

L'elenco di controllo seguente fornisce alcuni esempi per dimostrare la corretta gestione delle eccezioni.

Scrivi nel registro eccezioni

Scrivere nel registro eccezioni utilizzando il modello seguente, indipendentemente da ulteriori azioni, a meno che non vi sia un motivo valido per non farlo.

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

Questo approccio salva automaticamente $e->getMessage nel messaggio di registro e l'oggetto $e nel contesto, seguendo lo standard di contesto PSR-3. Operazione completata in \Magento\Framework\Logger\Monolog::addRecord.

Disattiva audio

Disattiva i segnali non registrando le eccezioni che fanno parte del flusso di operazioni previsto. Non è necessaria alcuna azione di follow-up quando si verifica l’eccezione, pertanto non è necessario registrarla e analizzarla quando si verifica. Aggiungete un commento che indica il motivo dell'audio disattivato e che è intenzionale. Combina con phpcs:ignore.

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

eccezioni di downgrade

Eseguire il downgrade delle eccezioni seguendo lo standard di contesto PSR-3.

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

La registrazione viene sempre prima

Come best practice, la registrazione viene sempre prima nel codice per evitare casi in cui viene generata un’altra eccezione o un errore irreversibile prima di scrivere nel registro.

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

Registra i messaggi e l'intera traccia dell'eccezione

Registra i messaggi e l'intera traccia dell'eccezione seguendo lo standard di contesto PSR-3.

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

Gestione delle eccezioni non corretta

Gli esempi seguenti mostrano una gestione errata delle eccezioni.

prima della registrazione

La logica prima della registrazione può causare un'altra eccezione o un errore irreversibile che impedisce la registrazione dell'eccezione e deve essere sostituita da esempio corretto.

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

Vuoto catch

I blocchi vuoti di catch possono essere un segnale di disattivazione audio non intenzionale e devono essere sostituiti dall'esempio corretto.

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

Doppia localizzazione

Se l'eccezione localizzata rilevata non è ancora stata tradotta, risolvere il problema nel punto in cui viene generata la prima volta.

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

Messaggi di registro e traccia in file di registro diversi

Il codice seguente registra erroneamente l'analisi dello stack per un'eccezione come stringa in un file di registro.

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

Questo approccio introduce interruzioni di riga nel messaggio, non conforme a PSR-3. L'eccezione, inclusa la traccia dello stack, deve far parte del contesto del messaggio per garantire che venga salvata correttamente con il messaggio in New Relic o in un altro archivio di registro compatibile con il monologo PSR-3.

Risolvere il problema sostituendo il codice seguendo gli esempi corretti mostrati in Scrivi nel registro eccezioni o Scaricare le eccezioni.

Eccezioni di downgrade senza contesto

L'eccezione viene ridotta a un errore, che non consente la trasmissione di un oggetto, ma solo di una stringa, da cui deriva getMessage(). Questo causa la perdita della traccia e deve essere sostituito dagli esempi corretti mostrati in Scrivi nel registro eccezioni o Scaricare le eccezioni.

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

registra solo il messaggio nel registro eccezioni

Invece di passare l'oggetto $e, viene passato solo $e->getMessage(). Questo causa la perdita della traccia e deve essere sostituito dagli esempi corretti mostrati Scrivi nel registro eccezioni o Scaricare le eccezioni.

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

Mancante // phpcs:ignore Magento2.CodeAnalysis.EmptyBlock.DetectedCatch

Omettendo la riga phpcs:ignore si attiva un avviso in PHPCS e non si deve trasmettere il CI. Questo deve essere sostituito dall'esempio corretto mostrato in Segnali audio.

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