<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-02-24 11:00 GMT+00:00 Marco Giusti <span dir="ltr"><<a href="mailto:marco.giusti@posteo.de" target="_blank">marco.giusti@posteo.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1n2" class="a3s" style="overflow:hidden">Io lancerei un'eccezione. Alcuni potrebbero non essere d'accordo con me,<br>
ma trovo le eccezioni chiare e autoesplicative se ben usate.<br></div></blockquote><div><br></div><div>In questo caso e' estremamente difficile essere in disaccordo...</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Collassare tutti gli errori possibili nel valore di ritorno e' pure un errore. Insomma... direi che qui le eccezioni sono proprio lo strumento giusto. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1n2" class="a3s" style="overflow:hidden">
<br>
Perché non ritornare un valore che sia esterno all'insieme dei risultati<br>
possibili? La prima volta che tu, o un altro per te, dimentica di<br>
controllare il valore di ritorno della funzione, è possibile che<br>
eccezioni del tipo "TypeError: unsupported operand type(s) for +:<br>
'NoneType' and 'str'" vengano sollevate. Questo nel migliore dei casi,<br>
perché se per un caso molto strano quel "None" finisce nel DB, potresti<br>
fornire a tutti gli "sconosciuti" la stessa sessione.<br>
<br>
Un bel AuthError invece è chiaro e può essere facilmente gestito ad un<br>
livello superiore.</div></blockquote><div><br></div><div>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. </div><div><br></div><div>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.</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>