[Python] Domanda stilistica

[enrico franchi]

2016-02-24 11:00 GMT+00:00 Marco Giusti <marco.giusti a posteo.de>:

> Io lancerei un'eccezione. Alcuni potrebbero non essere d'accordo con me,
> ma trovo le eccezioni chiare e autoesplicative se ben usate.
>

In questo caso e' estremamente difficile essere in disaccordo...

Le eccezioni vanno gestite comunque. Potrebbe esserci sotto un network
error o qualche altro errore che dice che non e' che le credenziali sono
invalide, ma qualcos'altro si e' spaccato (=> retry, maybe... dipende da
cosa). Ovviamente non c'e' modo elegante di codificare questo *in Python*
che non siano le eccezioni.

Si potrebbe dire che in questi casi tiri l'eccezione e se l'autenticazione
e' invalida usi un valore di ritorno... e il codice diventa un po' piu'
scomodo (poiche' bisogna gestire che il token sia None).

Nota per OP: se vai con i valori di ritorno, False e' sbagliato
chiaramente. None e' accettabile. Se il tuo token e' un oggetto "ricco",
potresti valutare un NullObjectPattern. Ma comunque lo fai, rimane piu'
complicato da usare che semplicemente usare le eccezioni anche per questo.

Collassare tutti gli errori possibili nel valore di ritorno e' pure un
errore. Insomma... direi che qui le eccezioni sono proprio lo strumento
giusto.


>
> Perché non ritornare un valore che sia esterno all'insieme dei risultati
> possibili? La prima volta che tu, o un altro per te, dimentica di
> controllare il valore di ritorno della funzione, è possibile che
> eccezioni del tipo "TypeError: unsupported operand type(s) for +:
> 'NoneType' and 'str'" vengano sollevate. Questo nel migliore dei casi,
> perché se per un caso molto strano quel "None" finisce nel DB, potresti
> fornire a tutti gli "sconosciuti" la stessa sessione.
>
> Un bel AuthError invece è chiaro e può essere facilmente gestito ad un
> livello superiore.
>

Concordo anche su queste considerazioni. Aggiungo che, in generale, e'
cattiva pratica avere una funzione che ritorna valori che non supportino
un'interfaccia (in senso lato) comune. Per esempio se mi aspetto che mi
ritorni un file-like su cui posso scrivere, mi aspetto che qualunque cosa
mi torni abbia il metodo write (e cosi' via). Una funzione che ogni tanto
ritorna stringhe, ogni tanto numeri, ogni tanto paperelle lascia sospetto.

None e' un po' l'edge case... fondamentalmente non supporta un tubo, ma
almeno si testa facilmente che e' proprio None. ovviamente complica il
codice costringendo fastidiosi if. Da cui il NullObjectPattern (che
ovviamente usato a cazzo non va bene manco lui). None e' proprio un
obrobrio che ci si porta dietro da troppo tempo in troppi linguaggi perche'
il type system e' troppo debole o troppo poco espressivo... ci sono pezze
(Optional) che hanno un prezzo ben diverso da un sano vecchio Maybe. Hoare
ne rivendica la paternita' (di Null/None o come vuoi chiamarlo) e lo
considera anche un errore che e' costato milioni di dollari all'industria.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20160224/404b52ba/attachment.html>