Devo controllare i parametri prima di usarli nei metodi? [duplicare]

Question

Devo controllare i parametri prima di usarli nei metodi? [duplicare]

#1 da (9 voti)
#2 da (2 voti)
#3 da (0 voti)

3

Creerò alcuni pacchetti PHP pubblici, seguire gli standard è una priorità per me.

PHP consente agli utenti di chiamare i metodi anche se non vi passano i parametri richiesti.

La mia domanda. Devo controllare i parametri prima di usarli nei metodi? (come nell'esempio seguente)

public function setVariable($value)
{
    if(isset($value))
        throw new \InvalidArgumentException("Value must be an int value!");
    $this->variable = (int) $value;
}

O fai il mio lavoro!

public function setVariable($value)
{
    $this->variable = (int) $value;
}

methods variables php

posta Milad 15.06.2015 - 14:50

fonte

3 risposte

2

A partire da PHP5, digitare hinting è una cosa . Le distinzioni più importanti sono le seguenti:

Non puoi digitare il suggerimento scalare / dati numerici, stringa, risorsa o tratto.
È possibile forzare i parametri che sono oggetti, matrici o funzioni anonime.
Puoi digitare il suggerimento utilizzando i nomi di interfaccia, i nomi di classe, la parola chiave object , la parola chiave array o la parola chiave callable (per funzioni anonime / callback).
Quando una funzione o un metodo di tipo suggerito viene chiamato con parametri non corrispondenti, si verificherà un errore irreversibile irreversibile (non un'eccezione).
Se si specifica null come valore predefinito, digitare hinting è in qualche modo inutile.

Suggerirei di controllare almeno isset e is_null prima di eseguire l'algoritmo e suggerisco caldamente di controllare il tipo con cose come is_string , is_int , is_float , ecc. Anche il casting di tipo è valido . Modifica: questo si applica solo quando non è possibile utilizzare il suggerimento del tipo per una funzione, ad es. parametri scalari.

Il ritorno di false o il lancio di un'eccezione sono tutte domande contestuali - devi determinare quale si adatta a ciascuna particolare funzione / algoritmo nel tuo pacchetto, che includerà considerando come qualcuno che usa il tuo codice dovrebbe interagire con esso. Il mio esempio preferito di lancio di eccezioni forzato è Sentry . Voglio dire, guarda tutti quei blocchi di cattura. Forse vorresti che il tuo codice generasse tante cose per fornire informazioni diverse, o forse puoi restituire un valore booleano, o forse puoi lanciare un new Exception("Message text") . È una scelta personale per ogni pezzo di codice. Ti consiglio di esaminare le potenziali applicazioni in cui il tuo pacchetto sarà utile e vedere quanto bene il tuo pacchetto si integrerebbe con quegli stili di codifica.

tl; versione dr

Le sole primitive che puoi tipo suggerimento sono array e object . È possibile digitare cast o type selezionare altre primitive. Chiamate di funzione / metodo con parametri che non riescono a soddisfare i suggerimenti di tipo si traduce in un errore fatale catchable. Che cosa fare quando i parametri inviati alla funzione / metodo non corrispondono, è una scelta personale specifica per il contesto a cui nessuno può rispondere in modo definitivo senza visualizzare il codice.

Modifica: vedi anche link

risposta data 15.06.2015 - 18:01

fonte

0

Provo a seguire quanto segue:

Per il codice chiamato esternamente, esegui il più possibile la gestione degli errori espliciti, per fornire la migliore esperienza per il chiamante e il massimo livello di protezione per il tuo codice contro i dati in entrata che potrebbero parzialmente riuscire in modi imprevisti.

Per le chiamate private, gestivo esplicitamente i dati errati se fosse possibile che quei dati passassero in qualche modo attraverso la chiamata senza fallire in modo violento da solo. Quindi, suppongo che chiamerei questo trapping difensivo.

Mi sembra che gli scrittori API debbano provare a gestire i dati non validi e fornire ottimi messaggi di errore su tutte le chiamate esterne, sia per aiutare l'utente sia per aiutare te stesso quando è necessario supportare alcuni problemi di produzione.

risposta data 15.06.2015 - 19:47

fonte

Leggi altre domande sui tag methods variables php

Che cosa significa la virgola in una definizione di funzione? In C ++, perché la funzione principale usa 'char * argv []'?

score 9 · Accepted Answer

I'm going to build some public public PHP packages.

Pubblico come in "Open Source", "pubblico in tutto il mondo"? Quindi fai un favore a te stesso e fai il maggior numero di convalide possibile finché non subisci gravi problemi di prestazioni. Anche quando fornisci della documentazione che dice "questa funzione non gestisce i parametri lasciati fuori", aspettati che molte persone ~~ignorino completamente la documentazione del tuo pacchetto~~ non leggendo tutti i dettagli cruenti della tua documentazione per intero. E se si verifica un problema, il messaggio di errore dovrebbe fornire agli utenti una descrizione chiara di ciò che hanno ha sbagliato, altrimenti daranno la colpa al tuo pacchetto, potrebbero dare la colpa a te e inviarti dozzine di messaggi di supporto.

Quindi consiglio non solo di lanciare un'eccezione, ma di rendere i tuoi messaggi di errore in quelle eccezioni il più chiaro possibile.