Utilizzo esteso di un'eccezione

3

Sono in procinto di costruire un sistema di routing per scopi di apprendimento e ho riscontrato un problema che ritengo sia un po 'nell'area grigia delle migliori pratiche. Ragazzi, potete aiutarmi a decidere se questo è sbagliato, okay o potrebbe essere fatto in un modo diverso.

Quando si risolve una richiesta in arrivo e una risorsa di percorso è stata abbinata, il metodo di richiesta HTTP viene convalidato rispetto ai metodi HTTP supportati dalla rotta per garantire che sia in grado di gestire tali richieste. In caso contrario, viene generata un'eccezione di tipo UnsupportedMethodException .

La documentazione del codice di stato HTTP indica che se un metodo di richiesta è negato / non supportato% L'intestazione diAllow contenente un elenco di metodi supportati deve essere restituita nella risposta.

10.4.6 405 Method Not Allowed

The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.

Quindi per ovviare a questo ho pensato di estendere l'utilizzo dell'eccezione altrimenti generica per richiedere una matrice sequenziale di metodi supportati nel suo costruttore.

class UnsupportedMethodException extends \RuntimeException {

    /**
     * A sequential array of supported HTTP request methods.
     *
     * @var array $supported
     */
    private $supported = [];

    /**
     * @param string     $message           The typical exception message.
     * @param array      $supportedMethods  A sequential array of HTTP request methods the matched route supports.
     * @param \Exception $previous          Any previous exceptions
     */
    public function __construct($message, array $supportedMethods, \Exception $previous = null)
    {
        parent::__construct($message, null, $previous);
        $this->supported = $supportedMethods;
    }

    /**
     * @return array
     */
    public function getSupportedMethods()
    {
        return $this->supported;
    }

}

Con l'uso del tipo hinting del blocco catch, ora ho un metodo solido per recuperare i metodi supportati e generare una risposta HTTP corretta.

Quindi la mia domanda è, pensate che sia una buona pratica? Qualcosa mi dice che la classe di eccezione non dovrebbe contenere tale logica, ma non ho alcuna prova / riferimento per eseguire il backup.

    
posta AnotherGuy 19.04.2015 - 20:02
fonte

3 risposte

3

Memorizzare le informazioni relative alla circostanza eccezionale nell'eccezione è sicuramente una buona cosa, in quanto può consentire a un gestore di correggere & riprovare o fallire con grazia. Non è logico ma dati, quindi non devi preoccuparti che la classe di eccezioni sia troppo complessa. Se l'eccezione ha preso un percorso ed ha estratto i metodi supportati, sarebbe stato troppo accoppiato, ma prendere i metodi come argomento è semplicemente stupido.

Altre domande, " Come scrivere un buon messaggio di eccezione " e " Perché molti messaggi di eccezione non contengono dettagli utili? ", sono strettamente correlati ma focalizzati sul messaggio, piuttosto che su altri campi di eccezione.

    
risposta data 19.04.2015 - 22:06
fonte
1

Se la tua eccezione contenesse effettivamente una logica, la prenderei, ma non lo è, quindi penso che vada bene. Quello che contiene è l'intervallo (l'insieme, in effetti) dei valori accettati, che non è una cattiva idea. (Potrebbe non essere necessario, perché l'intervallo di valori accettati è fisso e noto in anticipo, ma non è affatto male.)

Penso che dovrebbe contenere anche il nome del metodo che non è stato permesso, e probabilmente l'URI che ha fallito, poiché la risposta "Metodo non consentito" riguarda gli URI specifici. Questa informazione potrebbe non essere utile per costruire la risposta http, ma dovrebbe essere utile per la registrazione.

    
risposta data 20.04.2015 - 13:19
fonte
0

L'uso di un'eccezione per far parte del flusso di programma è un anti-pattern, non dovrebbero essere usati per cose che ti aspetti che accadano - da qui il nome!

Direi che la praticità supera comunque tali regole, ma qui mi chiederei perché si sta generando tale eccezione e semplicemente non si restituisce il codice del risultato 405 - se il metodo è riuscito, non si genera un'eccezione per restituire un 200 codice, quindi non vedo che lanciare questa eccezione è la migliore pratica qui.

Ma, se lo stai lanciando, chiamerei una funzione nel gestore di ritorno che recupera i metodi consentiti, non restituisce i dati tramite l'eccezione.

    
risposta data 20.04.2015 - 11:31
fonte

Leggi altre domande sui tag