Ausnahmebehandlung

Konfiguration

config/exception.php

return [
    // Hier die Ausnahmebehandlungsklasse konfigurieren
    '' => support\exception\Handler::class,
];

Im Mehranwendungsmodus kannst du für jede Anwendung eine eigene Ausnahmebehandlungsklasse konfigurieren. Siehe Mehrere Anwendungen.

Standard-Ausnahmebehandlungsklasse

In Webman werden Ausnahmen standardmäßig von der Klasse support\exception\Handler behandelt. Die Konfiguration in der Datei config/exception.php kann geändert werden, um die Standard-Ausnahmebehandlungsklasse zu ändern. Die Ausnahmebehandlungsklasse muss das Interface Webman\Exception\ExceptionHandlerInterface implementieren.

interface ExceptionHandlerInterface
{
    /**
     * Protokollierung
     * @param Throwable $e
     * @return mixed
     */
    public function report(Throwable $e);

    /**
     * Rendering der Antwort
     * @param Request $request
     * @param Throwable $e
     * @return Response
     */
    public function render(Request $request, Throwable $e) : Response;
}

Rendering der Antwort

Die Methode render in der Ausnahmebehandlungsklasse dient dazu, die Antwort zu rendern.

Wenn der Wert von debug in der Konfigurationsdatei config/app.php auf true gesetzt ist (im Folgenden app.debug=true), wird detaillierte Ausnahmeinformationen zurückgegeben, andernfalls werden verkürzte Ausnahmeinformationen zurückgegeben.

Wenn die Anfrage JSON erwartet, werden die zurückgegebenen Ausnahmeinformationen im JSON-Format zurückgegeben, ähnlich wie folgt:

{
    "code": "500",
    "msg": "Ausnahmeinformationen"
}

Wenn app.debug=true ist, wird im JSON-Daten eine zusätzliche trace-Option hinzugefügt, die den detaillierten Aufrufstapel zurückgibt.

Du kannst deine eigene Ausnahmebehandlungsklasse schreiben, um die Standard-Ausnahmebehandlungslogik zu ändern.

Geschäfts-Ausnahme BusinessException

Manchmal möchten wir eine Anfrage in einer bestimmten, geschachtelten Funktion abbrechen und eine Fehlermeldung an den Client zurückgeben. Dies kann durch das Auslösen von BusinessException erreicht werden.
Beispielsweise:

<?php
namespace app\controller;

use support\Request;
use support\exception\BusinessException;

class FooController
{
    public function index(Request $request)
    {
        $this->checkInput($request->post());
        return response('hello index');
    }

    protected function checkInput($input)
    {
        if (!isset($input['token'])) {
            throw new BusinessException('Parameterfehler', 3000);
        }
    }
}

Das obige Beispiel gibt eine

{"code": 3000, "msg": "Parameterfehler"}

Hinweis
Geschäfts-Ausnahme BusinessException muss nicht geschäftlich try-catch behandelt werden; das Framework fängt sie automatisch ab und gibt eine angemessene Ausgabe basierend auf dem Anfragetyp zurück.

Benutzerdefinierte Geschäfts-Ausnahme

Wenn die obigen Antworten nicht deinen Anforderungen entsprechen, z. B. wenn du msg in message umbenennen möchtest, kannst du eine eigene MyBusinessException erstellen.

Erstelle die Datei app/exception/MyBusinessException.php. Der Inhalt sollte wie folgt aussehen:

<?php

namespace app\exception;

use support\exception\BusinessException;
use Webman\Http\Request;
use Webman\Http\Response;

class MyBusinessException extends BusinessException
{
    public function render(Request $request): ?Response
    {
        // Bei JSON-Anfragen JSON-Daten zurückgeben
        if ($request->expectsJson()) {
            return json(['code' => $this->getCode() ?: 500, 'message' => $this->getMessage()]);
        }
        // Bei Nicht-JSON-Anfragen eine Seite zurückgeben
        return new Response(200, [], $this->getMessage());
    }
}

Wenn nun die Geschäftslogik

use app\exception\MyBusinessException;

throw new MyBusinessException('Parameterfehler', 3000);

ausgeführt wird, erhält eine JSON-Anfrage eine Ausgabe ähnlich der folgenden:

{"code": 3000, "message": "Parameterfehler"}

Hinweis
Da die BusinessException eine Geschäfts-Ausnahme darstellt (z. B. Benutzereingabeparameterfehler), ist sie vorhersehbar, und das Framework betrachtet sie nicht als schwerwiegenden Fehler und protokolliert sie daher nicht.

Zusammenfassung

Wenn du in irgendeinem Moment die aktuelle Anfrage abbrechen und Informationen an den Client zurückgeben möchtest, solltest du die Verwendung von BusinessException in Betracht ziehen.