Groups > it.comp.www.php > #22112 > unrolled thread

il ruolo di un validatore

Started by	alex <1j9448a02@lnx159sneakemail.com.invalid>
First post	2018-07-25 11:03 +0200
Last post	2018-08-06 07:17 +0000
Articles	20 on this page of 66 — 7 participants

Back to article view | Back to it.comp.www.php

  il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 11:03 +0200
    Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-07-25 02:36 -0700
      Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 13:31 +0200
        Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-07-25 05:50 -0700
          Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 17:13 +0200
          Re: il ruolo di un validatore enrico bosi <rnsrico@bo.b> - 2018-07-25 17:48 +0200
            Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-25 17:59 +0200
              Re: il ruolo di un validatore fmassei@gmail.com - 2018-07-25 09:53 -0700
    Re: il ruolo di un validatore fmassei@gmail.com - 2018-07-25 08:22 -0700
    Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-07-26 11:54 +0200
      Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-27 09:45 +0200
        Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-07-27 10:22 +0100
          Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-27 12:39 +0200
            Re: Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-07-28 13:01 +0200
              Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-07-29 11:22 +0200
                Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-07-29 12:18 +0200
                  Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-03 07:40 -0700
                    Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-04 09:40 +0200
                      Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-04 05:41 -0700
                  Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-10 19:45 +0200
                    Re: il ruolo di un validatore Umberto Salsi <salsi@icosaedro.it> - 2018-08-27 11:43 +0200
                      Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-30 11:21 +0200
          Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-01 08:26 +0200
            Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-05 15:51 +0100
              Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-05 18:56 +0200
                Re: il ruolo di un validatore alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-05 21:30 +0200
              Re: il ruolo di un validatore enrico bosi <rnsrico@bo.b> - 2018-08-06 16:33 +0200
                Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-06 07:47 -0700
                  Re: il ruolo di un validatore enrico bosi <rnsrico@bo.b> - 2018-08-06 22:47 +0200
                    Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-06 14:59 -0700
          [OT] Re: il ruolo di un validatore g4b0 <g4b0@nospam.com> - 2018-08-03 15:27 +0000
            Re: [OT] Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-03 08:35 -0700
            Re: [OT] Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-03 18:24 +0100
              Re: [OT] Re: il ruolo di un validatore fmassei@gmail.com - 2018-08-03 17:23 -0700
              Re: [OT] Re: il ruolo di un validatore g4b0 <g4b0@nospam.com> - 2018-08-06 07:52 +0000
                Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-06 10:22 +0100
                  Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) fmassei@gmail.com - 2018-08-06 08:10 -0700
                    Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-06 16:31 +0100
                      Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) fmassei@gmail.com - 2018-08-06 08:39 -0700
                        Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-06 18:03 +0100
                          Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) fmassei@gmail.com - 2018-08-06 10:29 -0700
                            Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-08 15:51 +0100
                              Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 07:02 +0000
                  Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-07 07:50 +0000
                    Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-07 16:30 +0100
                      Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-08 07:06 +0000
                        Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-08 13:27 +0200
                          Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-08 12:39 +0000
                            Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) alex <1j9448a02@lnx159sneakemail.com.invalid> - 2018-08-08 15:13 +0200
                              Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-08 13:44 +0000
                                Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-08 16:15 +0100
                                  Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 06:48 +0000
                        Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-08 16:57 +0100
                          Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 07:00 +0000
                            Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-09 11:28 +0100
                              Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 12:41 +0000
                                Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-09 13:50 +0100
                                  Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 15:27 +0000
                                    Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-09 15:31 +0000
                                    Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-09 18:23 +0100
                                      Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) g4b0 <g4b0@nospam.com> - 2018-08-10 07:26 +0000
                                        Re: Linguaggi di programmazione (era Re: [OT] Re: il ruolo di un validatore) Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-10 10:27 +0100
            Re: [OT] Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-08-03 23:04 -0700
              Re: [OT] Re: il ruolo di un validatore Alessandro Pellizzari <shuriken@amiran.it> - 2018-08-05 16:24 +0100
                Re: [OT] Re: il ruolo di un validatore fmigliori <fmigliori@gmail.com> - 2018-08-05 09:59 -0700
                  Re: [OT] Re: il ruolo di un validatore g4b0 <g4b0@nospam.com> - 2018-08-06 07:17 +0000

Page 1 of 4 [1] 2 3 4 Next page →

#22112 — il ruolo di un validatore

From	alex <1j9448a02@lnx159sneakemail.com.invalid>
Date	2018-07-25 11:03 +0200
Subject	il ruolo di un validatore
Message-ID	<pj9edi$1bk$1@gioia.aioe.org>

function rtrimValidate1($string) {
     if (substr($string, -1) == ' ') {// se finisce con ' '
         // aggiusto la situazione
         // (faccio qualche modifica al valore originale)
         $string = rtrim($string);
     }

     return $string;
}

function rtrimValidate2($string) {
     if (substr($string, -1) == ' ') {// se finisce con ' '
         // l'ancio l'apposita eccezione
         // e non mi prendo la responsabilità di fare aggiustamenti
         // (nessuna modifica al valore originale)
         throw new \Exception('Stringa non conforme.');
     }

     return $string;
}

Nel primo caso il validatore ha la facoltà di modificare il valore 
originale.

Nel secondo caso il validatore si limita solo a fare dei controlli.
Se qualcosa non è conforme lancia un'apposita eccezione, senza prendersi 
la responsabilità di modificare in alcun modo il valore originale.

Quindi, secondo gli standard di programmazione, quale dovrebbe essere il 
compito di un validatore?

[toc] | [next] | [standalone]

#22113

From	fmigliori <fmigliori@gmail.com>
Date	2018-07-25 02:36 -0700
Message-ID	<7474dfef-2c12-4882-8b26-e38880bf08cb@googlegroups.com>
In reply to	#22112

Il giorno mercoledì 25 luglio 2018 11:03:48 UTC+2, alex ha scritto:
> function rtrimValidate1($string) {
>      if (substr($string, -1) == ' ') {// se finisce con ' '
>          // aggiusto la situazione
>          // (faccio qualche modifica al valore originale)
>          $string = rtrim($string);
>      }
> 
>      return $string;
> }
> 
> function rtrimValidate2($string) {
>      if (substr($string, -1) == ' ') {// se finisce con ' '
>          // l'ancio l'apposita eccezione
>          // e non mi prendo la responsabilità di fare aggiustamenti
>          // (nessuna modifica al valore originale)
>          throw new \Exception('Stringa non conforme.');
>      }
> 
>      return $string;
> }
> 
> Nel primo caso il validatore ha la facoltà di modificare il valore 
> originale.
> 
> Nel secondo caso il validatore si limita solo a fare dei controlli.
> Se qualcosa non è conforme lancia un'apposita eccezione, senza prendersi 
> la responsabilità di modificare in alcun modo il valore originale.
> 
> Quindi, secondo gli standard di programmazione, quale dovrebbe essere il 
> compito di un validatore?

1. Il validatore non dovrebbe restituire la stringa d'origine ma bool, altrimenti è un'altra cosa. Al suo interno può manipolare il dato anche se forse sarebbe meglio farlo esternamente, dipende dalle situazioni.

2. Il fatto che venga passato un parametro non valido fa parte della normalità di un validatore e non dovrebbe lanciare un'eccezione. Però anche qui dipende dalle situazioni.

[toc] | [prev] | [next] | [standalone]

#22114

From	alex <1j9448a02@lnx159sneakemail.com.invalid>
Date	2018-07-25 13:31 +0200
Message-ID	<pj9n2d$i5m$1@gioia.aioe.org>
In reply to	#22113

Il 25/07/2018 11:36, fmigliori ha scritto:
> 1. Il validatore non dovrebbe restituire la stringa d'origine ma bool, altrimenti è un'altra cosa.

Che cosa?
Un *sanitizer* ad esempio?

> Al suo interno può manipolare il dato anche se forse sarebbe meglio farlo esternamente, dipende dalle situazioni.
> 
> 2. Il fatto che venga passato un parametro non valido fa parte della normalità di un validatore e non dovrebbe lanciare un'eccezione. Però anche qui dipende dalle situazioni.

In pratica dovrebbe solo verificare la validità di un valore, e di 
conseguenza restituire TRUE o FALSE?

[toc] | [prev] | [next] | [standalone]

#22115

From	fmigliori <fmigliori@gmail.com>
Date	2018-07-25 05:50 -0700
Message-ID	<5310210e-fca5-4936-9074-37333d082c25@googlegroups.com>
In reply to	#22114

Il giorno mercoledì 25 luglio 2018 13:31:28 UTC+2, alex ha scritto:
> Il 25/07/2018 11:36, fmigliori ha scritto:
> > 1. Il validatore non dovrebbe restituire la stringa d'origine ma bool, altrimenti è un'altra cosa.
> 
> Che cosa?
> Un *sanitizer* ad esempio?
> 
> > Al suo interno può manipolare il dato anche se forse sarebbe meglio farlo esternamente, dipende dalle situazioni.
> > 
> > 2. Il fatto che venga passato un parametro non valido fa parte della normalità di un validatore e non dovrebbe lanciare un'eccezione. Però anche qui dipende dalle situazioni.
> 
> In pratica dovrebbe solo verificare la validità di un valore, e di 
> conseguenza restituire TRUE o FALSE?


Ricordo che stiamo ragionando su convenzioni associate ad una parola, quindi il risultato può cambiare in contesti diversi.

Faccio un esempio. Devo valutare che il valore $input contenga una data nel formato corretto.

$data = uniformaSegni($input); // converte '/' '.' ' ' in '-'  e trimma (Possiamo considerarlo simile ad un purificatore)
if(!dataCorretta($data))
{
//gestire errore
}
//uso la variabile purificata $data

Nella mia visione se l'errore NON può essere corretto dall'utente al volo e blocca la procedura, magari in background allora

$data = uniformaSegni($input); // converte '/' '.' ' ' in '-'  (Possiamo considerarlo simile ad un purificatore)
try
{
dataCorretta($data); //lancia l'eccezione
//altre istruzioni
}
catch(EccezioneValidazioneData $e)
{
throw new Exception('Messaggio errore di alto livello',5,$e);
}

Anche se mi pare strano che un validatore si debba scaldare tanto.


Se la data 'purificata' non viene usata nel programma a quel punto può essere un'operazione svolta nel validatore.

[toc] | [prev] | [next] | [standalone]

#22116

From	alex <1j9448a02@lnx159sneakemail.com.invalid>
Date	2018-07-25 17:13 +0200
Message-ID	<pja43d$1al6$1@gioia.aioe.org>
In reply to	#22115

Il 25/07/2018 14:50, fmigliori ha scritto:
> 
> Ricordo che stiamo ragionando su convenzioni associate ad una parola, quindi il risultato può cambiare in contesti diversi.

OK

> Faccio un esempio. Devo valutare che il valore $input contenga una data nel formato corretto.
> 
> $data = uniformaSegni($input); // converte '/' '.' ' ' in '-'  e trimma (Possiamo considerarlo simile ad un purificatore)
> if(!dataCorretta($data))
> {
> //gestire errore
> }
> //uso la variabile purificata $data

Gestire errore?

> Nella mia visione se l'errore NON può essere corretto dall'utente al volo e blocca la procedura, magari in background allora

????
Non ho capito.

> $data = uniformaSegni($input); // converte '/' '.' ' ' in '-'  (Possiamo considerarlo simile ad un purificatore)
> try
> {
> dataCorretta($data); //lancia l'eccezione
> //altre istruzioni
> }
> catch(EccezioneValidazioneData $e)
> {
> throw new Exception('Messaggio errore di alto livello',5,$e);
> }

Qui invece dataCorretta() invece di restituire false, genera un'eccezione.
Da quello che ho capito...

> Anche se mi pare strano che un validatore si debba scaldare tanto.

????
Boh...

> Se la data 'purificata' non viene usata nel programma a quel punto può essere un'operazione svolta nel validatore.

Certo, se lo dici tu :D
Purtroppo faccio un po' di fatica a capirti :D

[toc] | [prev] | [next] | [standalone]

#22118

From	enrico bosi <rnsrico@bo.b>
Date	2018-07-25 17:48 +0200
Message-ID	<pja64h$1efc$1@gioia.aioe.org>
In reply to	#22115

Il 25/07/2018 14:50, fmigliori ha scritto:
> 
> Anche se mi pare strano che un validatore si debba scaldare tanto.

Siamo ancora in estate :D

[toc] | [prev] | [next] | [standalone]

#22119

From	alex <1j9448a02@lnx159sneakemail.com.invalid>
Date	2018-07-25 17:59 +0200
Message-ID	<pja6p6$1ful$1@gioia.aioe.org>
In reply to	#22118

Il 25/07/2018 17:48, enrico bosi ha scritto:
> Il 25/07/2018 14:50, fmigliori ha scritto:
>>
>> Anche se mi pare strano che un validatore si debba scaldare tanto.
> 
> Siamo ancora in estate :D

Ma ormai il lessico italiano l'abbiamo mandato in vacanza tutto l'anno :D
Povera madrelingua :)

[toc] | [prev] | [next] | [standalone]

#22120

From	fmassei@gmail.com
Date	2018-07-25 09:53 -0700
Message-ID	<5a8ee6f7-a900-433b-8243-ff3bd269b9c7@googlegroups.com>
In reply to	#22119

On Wednesday, July 25, 2018 at 11:59:37 AM UTC-4, alex wrote:
> Il 25/07/2018 17:48, enrico bosi ha scritto:
> > Il 25/07/2018 14:50, fmigliori ha scritto:
> >>
> >> Anche se mi pare strano che un validatore si debba scaldare tanto.
> > 
> > Siamo ancora in estate :D
> 
> Ma ormai il lessico italiano l'abbiamo mandato in vacanza tutto l'anno :D
> Povera madrelingua :)
>

?
C'è un errore che non vedo?
A me sembra corretto, anche un po' aulico.


Ciao!

[toc] | [prev] | [next] | [standalone]

#22117

From	fmassei@gmail.com
Date	2018-07-25 08:22 -0700
Message-ID	<5ddbbaa9-db81-47c6-909f-72dfa37b1410@googlegroups.com>
In reply to	#22112

On Wednesday, July 25, 2018 at 5:03:48 AM UTC-4, alex wrote:
> Nel primo caso il validatore ha la facoltà di modificare il valore 
> originale.
> 

Allora è un sanitizer.

> Nel secondo caso il validatore si limita solo a fare dei controlli.
> Se qualcosa non è conforme lancia un'apposita eccezione, senza prendersi 
> la responsabilità di modificare in alcun modo il valore originale.
> 

Basta che torni false.

> Quindi, secondo gli standard di programmazione, quale dovrebbe essere il 
> compito di un validatore?

In PHP la c'è la funzione filter_var() che fa proprio questi compiti. Se
ne devi scrivere una custom, io cercherei di farla comportare come quella
nativa.


Ciao!

[toc] | [prev] | [next] | [standalone]

#22121

From	Umberto Salsi <salsi@icosaedro.it>
Date	2018-07-26 11:54 +0200
Message-ID	<pjc5q9$ghl$1@gioia.aioe.org>
In reply to	#22112

alex <1j9448a02@lnx159sneakemail.com.invalid> wrote:

> Quindi, secondo gli standard di programmazione, quale dovrebbe essere il 
> compito di un validatore?

Secondo me:

- Una funzione di parsing

	/**
	 * @param string $s
	 * @return int
	 * @throws ParseException
	 */
	function parseInt($s){...}

accetta una stringa come "   +0001234  " e ritorna il dato nella
rappresentazione conveniente per il programma, per esempio int 1234. Una
eccezione viene generata se il valore non è parsabile oppure è fuori del
range per int. Il livello di tolleranza agli spazi e alle mille varianti
delle rappresentazioni dei dati va scelto qui. Altri casi classici sono
il parsing degli importi monetari "1.234,56" e il parsing delle date,
che in generale coinvolgono le preferenze dell'utente.

- Una funzione di validazione

	/**
	 * @param string $s
	 * @return boolean
	 */
	function isValidInt($s){...}

accetta la stringa e ritorna TRUE se il dato è parsabile oppure FALSE
se non lo è. L'implementazione più semplice di questa funzione è
chiamare il parser e vedere se lancia una eccezione. Una implementazione
specifica richiede invece il perfetto allineamento con il criterio di
tolleranza del parser, tale per cui se la validazione è ok, il parser
non darà eccezione.

- Una funzione di sanitizzazione

	/**
	 * @param T $x
	 * @return T
	 */
	function sanitizeT($x){...}

accetta il dato di un tipo e ritorna lo stesso tipo; se il valore è
accettabile lo ritorna tal quale, altrimenti lo modidica silentemente
per adattarlo oppure lo sostituisce completamente. Per esempio, per una
stringa si tolgono i caratteri non validi, si trimma, si tronca alla
lunghezza massima consentita; il valore int 123456789 troppo grande
per una data applicazione potrebbe ritornare forzato a un dato range
[min,max] previsto dall'applicazione.

- Una funzione di conversione

	/**
	 * @param X $x
	 * @return Y
	 * @throws CastException
	 */
	function XToY($x){...}

accetta un dato di tipo X e ritorna un dato di tipo Y; se la conversione
fallisce viene emessa eccezione. La funzioni di parsing sono particolari
tipi di funzioni di conversione che agiscono su stringhe.

- Una funzione di formattazione

	/**
	 * @param T $x
	 * @return string
	 */
	function formatT($x){...}

prende il dato nella sua rappresentazione interna del programma e lo restituisce
in forma di stringa. E' la funzione inversa del parsing.

Una soluzione sistematica per tenere insieme il codice è fare una classe per ogni
tipo specifico applicando questa ricetta (è la mia check list):

class T {
	static function parse($s){...}
	static function fromX($x){...}
	static function isValid($s){...}
	function toX(){...}
	function toY(){...}
	function toZ(){...}
	function format(){...}
	function __toString(){...}
}

Ovviamente, parse($s) parsa la stringa $s e ritorna un oggetto T;
fromX($x) converte $x in T;
toX() converte l'istanza di T nel valore di tipo X;
format() converte l'istanza di T in una stringa;
__toString() converte l'istanza di T nelle sua rappresentazione canonica
più comune, ed è molto utile nel debugging perché così il PHP sà
già come trasformare il dato in stringa.

E dato che ci siamo, nella definizione della classe conviene anche
porsi il problema dell'eventuale clonabilità (methodo __clone()),
serializzabilità (interfaccia Serializable), comparabilità equals($x),
ordinamento compareTo($x) e hashing getHash() secondo il caso. Purtroppo
per comparabilità, ordinamento e hashing il PHP standard non ha
definito delle interfacce specifiche, per cui è difficile scrivere
codice intelligente e bisogna arrangiarsi in proprio, ma questo è un
altro discorso.

Ciao,
 ___ 
/_|_\  Umberto Salsi
\/_\/  www.icosaedro.it

[toc] | [prev] | [next] | [standalone]

#22122

From	alex <1j9448a02@lnx159sneakemail.com.invalid>
Date	2018-07-27 09:45 +0200
Message-ID	<pjeiic$9iv$1@gioia.aioe.org>
In reply to	#22121

Il 26/07/2018 11:54, Umberto Salsi ha scritto:
> ...

Una funzione di filtraggio?
Per me è così:

function filter_dir($dir) {
	return is_dir($dir) ?
		$dir :
		false
	;
}

Restituisce FALSE se il valore non è valido, oppure lo stesso valore 
originale.

[toc] | [prev] | [next] | [standalone]

#22123

From	Alessandro Pellizzari <shuriken@amiran.it>
Date	2018-07-27 10:22 +0100
Message-ID	<fs06jhF9eqeU1@mid.individual.net>
In reply to	#22122

On 27/07/2018 08:45, alex wrote:

> Una funzione di filtraggio?
 > ...
> Restituisce FALSE se il valore non è valido, oppure lo stesso valore 
> originale.

Una funzione di filtraggio dovrebbe sempre tornare un valore usabile, o 
lanciare un'eccezione in caso di errori.

Una di validazione, in genere, dovrebbe tornare solo true o false.

In questo modo le puoi comporre.

Tornare tipi diversi porta ad avere casini alla fine, ed è uno dei punti 
più odiati di PHP (per esempio alcune funzioni tornano un oggetto se va 
tutto bene, false se non hanno trovato la parte da modificare, null in 
caso di errori. Puntualmente ci si dimentica di gestire uno dei casi.

Bye.

[toc] | [prev] | [next] | [standalone]

#22124

From	alex <1j9448a02@lnx159sneakemail.com.invalid>
Date	2018-07-27 12:39 +0200
Message-ID	<pjeso5$rc8$1@gioia.aioe.org>
In reply to	#22123

Il 27/07/2018 11:22, Alessandro Pellizzari ha scritto:
> 
> Una funzione di filtraggio dovrebbe sempre tornare un valore usabile, o 
> lanciare un'eccezione in caso di errori.

http://php.net/manual/en/function.filter-var.php
Return Values
Returns the filtered data, or FALSE if the filter fails.

Mettiamoci d'accordo.

[toc] | [prev] | [next] | [standalone]

#22125

From	Umberto Salsi <salsi@icosaedro.it>
Date	2018-07-28 13:01 +0200
Message-ID	<pjhiev$tm8$1@gioia.aioe.org>
In reply to	#22124

alex <1j9448a02@lnx159sneakemail.com.invalid> wrote:

> Il 27/07/2018 11:22, Alessandro Pellizzari ha scritto:
> > 
> > Una funzione di filtraggio dovrebbe sempre tornare un valore usabile, o 
> > lanciare un'eccezione in caso di errori.
> 
> http://php.net/manual/en/function.filter-var.php
> Return Values
> Returns the filtered data, or FALSE if the filter fails.
> 
> Mettiamoci d'accordo.

P.S. (pre-scriptum) Mi sono accorto che ho scritto uno sbrodolo
come al solito.  Chi va di fretta perché parte per le vacanze può
tranquillamente evitare :-)

Le origini del PHP sono umili e la barriera di ingresso per i
non-programmatori è molto bassa, consentento a tanti novizi l'ingresso
nel magico mondo del web (a me, per esempio) pur senza avere una adeguata
preparazione teorica e senza avere né il tempo né la voglia di farsela.
E' a questo genere di utilizzatori che il PHP si rivolge, ed è su questi
criteri che gli sviluppatori storici non ammettono deroghe (ne andrebbe
del successo stesso del linguaggio, dove i difetti lamentati da pochi
sono proprio i pregi apprezzati dai più). Ecco perché le funzioni di
libreria standard continuano a ignorare la disponibilità delle eccezioni
e così prevedo che sarà ancora per molto tempo, anche con PHP 8.

Poi però i progetti si fanno più articolati e complessi, i tempi
di debugging si allungano in modo spropositato, tenere insieme tutto
l'ambaradam diventa anche più costoso che scriverlo la prima volta,
per cui la safety non è più un concetto astratto per i manualoni di
teoria, ma diventa un imperativo per tagliare tempi e costi e mantenere
il controllo sul progetto.

"Mantenere il controllo sul progetto" per me vuol dire sapere sempre se
qualcosa è andato storto. Ecco perché le eccezioni sono una manna per
semplificare il programma pur mantenendo intatta la safety.

Premesso che io mappo sempre gli errori in ErrorException (incluso anche
gli "insignificanti" E_NOTICE che spesso rilevano eventi catastrofici, vedi
appendice 1),

	error_reporting(PHP_INT_MAX);

	function my_error_handler($errno, $message) {
		throw new ErrorException($message);
	}
	set_error_handler("my_error_handler");

	function my_exception_handler($e)
	{
		error_log( "Uncaught $e");
		exit(1);
	}
	set_exception_handler("my_exception_handler");

due sono le strategie che si possono adottare:

1. Ignorare del tutto le eccezioni. La scrittura del codice si semplifica
enormemente perché non è più necessario testare il valore di ritorno
della funzioni:

	$f = fopen("last-update-date.txt", "rb");
	$s = fread($f, 999);
	...
	fclose($f);
	$upd = DateTimeTZ::parse( trim($s) );
	echo "Last update time was: $upd";

Qui assumo che il file da leggere esista realmente, che sia leggible,
e che contenga una data valida parsabile da una certa mia classe
DateTimeTZ. Se qualcosa va storto nella lettura del file ho un
ErrorException; se qualcosa va storto nel parsing ho un ParseException.

Questa implementazione è perfetta per i programmi destinati a fare quello
che ci sia aspetta che facciano oppure muoiano nell'intento; non sono
previste mezze misure perché non sarebbero safe. Nell'esempio specifico,
se non riesco a determinare l'ultima data di aggiornamento di un certo
qualcosa, è inutile continuare perché rischierei di fare aggiornamenti
continui o non farli mai senza capire che cosa sta succedendo.

Il programma rimane safe perché se qualcosa va storto mi ritrovo il
messaggio di errore nei log con tanto di stack trace, per cui posso
intervenire puntualmente a correggere il problema. Intanto l'utente si
è beccato una pagina vuota o incompleta (cosa che per i programmatori
PHP è come l'aglio per i vampiri) ma siccome monitoro con regolarità i
log files, e siccome faccio in modo che siano sempre vuoti, sono sicuro
di poter risolvere rapidamente.

2. Gestire le eccezioni. Vuol dire catturarle con try/catch e gestirle
quando esiste un piano B da applicare, oppure quando il problema non
riguarda il programma in sé ma l'accesso a una risorsa esterna e vogliamo
dare una retroazione puntuale via interfaccia utente.

Nel tempo ho scoperto che sono pochi i casi in cui realmente esiste un
piano B (va già grassa se il programma ha un piano A da svolgere e lo
fa bene), per cui è inutile catturare le eccezioni per questo fine. E ho
anche scoperto che è quasi sempre inutile dare all'utente una retroazione
puntuale e tecnica del problema accaduto in qualche recesso interno del
programma, cosa che sarebbe per lui del tutto inutile.

Ho invece scoperto che nei rari casi in cui uso try/catch lo faccio per
trasformare una eccezione di basso livello (per esempio un ErrorException)
in un'altra di più alto livello specifica del blocco di programma,
oppure catturo l'eccezione per "rimettere a posto" le cose prima di
rilanciarla.  In definitiva, ho scoperto che il try/catch serve raramente,
e che il compito di intercettare le eccezioni spetta ai piani alti del
programma, là dove si gestire l'interfaccia utente oppure si gestisce la
logica generale del programma; è lì e solo lì che bisogna catturare
le eccezioni.  Diventa quindi fondamentale sfruttare il meccanismo di
propagazione automatico della eccezioni, cosa che non si può fare o è
estremamente difficile fare con gli altri sistemi.

Il tutto va naturalmente condito con un validatore statico di sorgente
capace di tracciare la propagazione delle eccezioni e capace di dire dove
si originano, dove sono gestite, dove vengono deliberatamente propagate e,
soprattutto, dove ci si è dimenticati di fare questa scelta fondamentale
tra gestione locale o propagazione. E' anche per questo che mi sono
dovuto scrivere il mio validatore statico PHPLint, con il quale si può
puntare a un livello di safety paragonabile a Java ed irraggiungibile con
qualunque altro sistema o linguaggio (neppure con C++, C# e compagnia).
"php -l" semplicemente non serve a niente.

Il discorso cambia completamente quando ci si affida al testing del valore
di ritorno delle funzioni. I programmatori diligenti testano il valore
di ritorno di ogni singola funzione, ma si accorgono che si tratta di una
"mission impossible" perché il codice diventa un orrore del tipo:

	$f = fopen(...);
	if( $f === NULL ){
		// Mo' che faccio? Bò!
		die("fopen fallito");
	}
	ecc. ecc.

Quando lo sbrodolo si è allungato abbastanza decide per la scrittura
concisa, che fa molto hacker:

	$f = fopen(...) || die(...);

Purtroppo non si avrà uno stack trace, per cui sarà difficile indagare
sul punto dove si è verificato il problema, mentre il codice si "sporca"
e presto passa la voglia, si rinuncia a gestire gli errori, mentre il
log file si allunga, e finalmente si opta per nascondere gli errori da
php.ini nel sito di produzione. Che poi è l'ultimo e più grave errore
da fare per qualunque cosa appena più importante del blog personale.

In definitiva, le funzioni che ritornano NULL, FALSE o -1 su errore,
o altre cose ancora, non sono "safe" perché se il programmatore si
dimentica di verificare il valore ritornato, il programma prosegue
ciecamente andando incontro a un destino orribile e imprevedibile:
corruzione dei dati, presentazione all'utente di ridicoli dati sballati,
corruzione del data base, crash inaspettato centinaia di righe più
avanti nel codice che è poi difficile da diagnosticare.

Inoltre non è possibile propagare gli errori ai piani alti del programma
ma costringe a gestirli localmente oppure rinunciare; non è possibile
avere lo stack trace; non è possibile veicolare preziose informazioni
quali il tipo di errore ed eventuali dettagli specifici che invece
un oggetto può trasportare. Tutto questo rende i programmi unsafe,
difficili e frustranti da debuggare, e allunga i tempi di rilascio.

APPENDICI

1. Istruzioni e funzioni che generano un "insignificante" E_NOTICE su errore
che normalmente viene spento nel "sito in produzione":

- GET['n'] quando il dato 'n' non c'è.

- unserialize() se i dati sono corrotti e non è possibile ricostruire
  il valore.

- Quasi tutti i metodi e funzioni di DOM, iconv e tidy danno anche
un E_NOTICE se c'è un problema; non sempre in questi casi il valore
ritornato è un FALSE o un NULL, ma spesso è semplicemente una cosa
imprevedibile perché la funzione non ha fatto quello che il programma
si aspettava.

- Probabilmente molti altri casi che adesso non mi vengono in mente o
non sono documentati nel manuale.

Ciao,
 ___ 
/_|_\  Umberto Salsi
\/_\/  www.icosaedro.it

[toc] | [prev] | [next] | [standalone]

#22126

From	alex <1j9448a02@lnx159sneakemail.com.invalid>
Date	2018-07-29 11:22 +0200
Message-ID	<pjk16s$jt4$1@gioia.aioe.org>
In reply to	#22125

Il 28/07/2018 13:01, Umberto Salsi ha scritto:
> 2. Gestire le eccezioni. Vuol dire catturarle con try/catch e gestirle
> quando esiste un piano B da applicare, oppure quando il problema non
> riguarda il programma in sé ma l'accesso a una risorsa esterna e vogliamo
> dare una retroazione puntuale via interfaccia utente.

Retroazione?
In cosa consisterebbe?

[toc] | [prev] | [next] | [standalone]

#22127

From	Umberto Salsi <salsi@icosaedro.it>
Date	2018-07-29 12:18 +0200
Message-ID	<pjk49g$p3b$1@gioia.aioe.org>
In reply to	#22126

alex <1j9448a02@lnx159sneakemail.com.invalid> wrote:

> Il 28/07/2018 13:01, Umberto Salsi ha scritto:
> > 2. Gestire le eccezioni. Vuol dire catturarle con try/catch e gestirle
> > quando esiste un piano B da applicare, oppure quando il problema non
> > riguarda il programma in sé ma l'accesso a una risorsa esterna e vogliamo
> > dare una retroazione puntuale via interfaccia utente.
> 
> Retroazione?
> In cosa consisterebbe?

Per "retroazione puntuale" intendo avvisare l'utente che c'è stato un problema
specifico al sistema, evitando inutili dettagli tecnici. Per esempio:

$query = "select ....";
try {
	$res = $db->query($query);
}
catch(SQLException $e){

	// Log issue on server, with stack trace:
	error_log("failed query: $query: $e");

	// User feedback:
	?>
	Siamo spiacenti, ma si è verificato un problema nel nostro
	sistema nel compiere quest'ultima operazione.  Il personale
	tecnico è stato già avvertito e sta lavorando alacremente per
	risolverlo quando prima. Ti preghiamo di riprovare più tardi.
	Grazie.
	<?php
	exit(0);
}

La gestione puntuale delle eccezioni dà la possibilità al programma
di loggare dettagli specifici sull'operazione in corso, come ad esempio
la query SQL che è fallita, l'identità dell'utente, ecc. Poiché i
possibili contesti di esecuzione di una operazione sono infiniti, solo
il programmatore conosce quali dettagli è opportuno loggare caso per
caso. La conoscenza del contesto in cui si è verificato l'errore aiuta
a risolverlo.

L'alternativa è non catturare l'eccezione e lasciare che il programma
muoia in modo naturale, e allora:

1. L'eccezione non gestita dal programma verrà catturata dalla funzione
my_exception_handler() del mio messaggio precedente, che a sua volta
registra l'eccezione su error log e fa un exit(1). Uno stack trace
contiene già moltissime info utili, ma a volte manca di contesto e
quindi è più difficile intervenire.

2. L'utente riceve un HTTP 500 "Internal server error" se non c'è stato
ancora output, altrimenti vedrà una pagina inspiegabilmente incompleta.
Di norma ogni pagina viene generata prima raccogliendo tutti i dati
necessari, e poi producendo l'output, sicché l'utente dovrebbe ottenere
un 500, che è meglio di una pagina inspiegabilmente incompleta.

In entrambi i casi, l'error log dirà quello che c'è da fare, con o
senza feedback puntuale all'utente, e questa è la cosa più importante.

Tutte queste attenzioni, naturalmente, vanno dedicate solo alle eccezioni
che coinvolgono risorse esterne al programma (connessioni di rete,
data base, file system, ecc.) e quando il programma è interattivo
(in pratica, una pagina web).

Non è il caso di sbattersi nel gestire eccezioni e feedback quando:

- Il programma è una procedura batch (o va o non va e amen).

- Per le eccezioni interne del programma (RuntimeException e derivate,
per esempio) che non dovrebbero mai verificarsi. L'assunto è: il mio
programma è perfetto e sa reagire alle avversità esterne, altrimenti
muore con disonore (ma con eccezione loggata, però).

- Siamo pagati a ore per la manutenzione del sistema, e più sono oscuri
e indecifrabili i problemi che si verificano, più tempo impiegheremo e
più ore potremo fatturare.

Ciao,
 ___ 
/_|_\  Umberto Salsi
\/_\/  www.icosaedro.it

[toc] | [prev] | [next] | [standalone]

#22129

From	fmassei@gmail.com
Date	2018-08-03 07:40 -0700
Message-ID	<feeeeb08-5241-4d50-a9bc-c54b836ea6f9@googlegroups.com>
In reply to	#22127

On Sunday, July 29, 2018 at 6:18:26 AM UTC-4, Umberto Salsi wrote:
> <snip>
>

Su tutto quello che hai scritto vorrei giusto dire che è un'opinione tua
:)

> Non è il caso di sbattersi nel gestire eccezioni e feedback quando: 
> - Siamo pagati a ore per la manutenzione del sistema, e più sono oscuri
> e indecifrabili i problemi che si verificano, più tempo impiegheremo e
> più ore potremo fatturare.
> 

Visto che il tempo speso a scrivere "bene" o "male" è più o meno lo stesso,
meglio scrivere direttamente bene. Se il tuo scopo è fregare i clienti puoi
sempre segnare più ore di manutenzione di quante non te ne servano.

Ciao!

[toc] | [prev] | [next] | [standalone]

#22135

From	alex <1j9448a02@lnx159sneakemail.com.invalid>
Date	2018-08-04 09:40 +0200
Message-ID	<pk3lhe$1mrv$1@gioia.aioe.org>
In reply to	#22129

Il 03/08/2018 16:40, fmassei@gmail.com ha scritto:


Già che ci troviamo, la differenza tra un filtro e un sanitizzer?

[toc] | [prev] | [next] | [standalone]

#22136

From	fmassei@gmail.com
Date	2018-08-04 05:41 -0700
Message-ID	<06b6e3fe-1645-4179-a480-f0ec8af6d4ff@googlegroups.com>
In reply to	#22135

On Saturday, August 4, 2018 at 3:44:48 AM UTC-4, alex wrote:
> Il 03/08/2018 16:40, fmassei@gmail.com ha scritto:
> 
> Già che ci troviamo, la differenza tra un filtro e un sanitizzer?
>

Per la nomenclatura della filter_var, un sanitizer è un tipo di filtro.


Ciao!

[toc] | [prev] | [next] | [standalone]

#22188

From	alex <1j9448a02@lnx159sneakemail.com.invalid>
Date	2018-08-10 19:45 +0200
Message-ID	<pkkj6q$11hf$1@gioia.aioe.org>
In reply to	#22127

Il 29/07/2018 12:18, Umberto Salsi ha scritto:
> try {
> 	$res = $db->query($query);
> }
> catch(SQLException $e){
> 
> 	// Log issue on server, with stack trace:
> 	error_log("failed query: $query: $e");
> 
> 	// User feedback:
> 	?>
> 	Siamo spiacenti, ma si è verificato un problema nel nostro
> 	sistema nel compiere quest'ultima operazione.  Il personale
> 	tecnico è stato già avvertito e sta lavorando alacremente per
> 	risolverlo quando prima. Ti preghiamo di riprovare più tardi.
> 	Grazie.
> 	<?php
> 	exit(0);
> }

Ma invece di invocare implicitamente il metodo __toString(), non sarebbe 
più giusto invocare il metodo __debugInfo() (tramite print_r($e, true)) 
che è fatto apposta per restituire un array con i dati di debug?

[toc] | [prev] | [next] | [standalone]

Page 1 of 4 [1] 2 3 4 Next page →

csiph-web

il ruolo di un validatore

Contents

#22112 — il ruolo di un validatore

#22113

#22114

#22115

#22116

#22118

#22119

#22120

#22117

#22121

#22122

#22123

#22124

#22125

#22126

#22127

#22129

#22135

#22136

#22188