<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-02-28 21:04 GMT+00:00 Nicola Larosa <span dir="ltr"><<a href="mailto:nico@teknico.net" target="_blank">nico@teknico.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Enrico Franchi wrote:<br>
> si potrebbe avere anche la convenzione di ritornare *sempre* una tupla<br>
> con qualcosa che indica l'errore. In Go si fa cosi' (o per lo meno, e'<br>
> diffuso)<br>
<br>
</span>No no, che diffuso, il modo è quello e basta, vedi blog ufficiale:<br>
<br>
Error handling and Go<br>
<<a href="http://blog.golang.org/error-handling-and-go" target="_blank">http://blog.golang.org/error-handling-and-go</a>><br>
<br>
Defer, Panic, and Recover<br>
<<a href="http://blog.golang.org/defer-panic-and-recover" target="_blank">http://blog.golang.org/defer-panic-and-recover</a>><br>
<br>
nonché l'autorevole Dave Cheney:<br>
<br>
Why Go gets exceptions right<br>
<<a href="http://dave.cheney.net/2012/01/18/why-go-gets-exceptions-right" target="_blank">http://dave.cheney.net/2012/01/18/why-go-gets-exceptions-right</a>><span class=""><br></span></blockquote><div><br></div><div>Il modo e' quello perche' la stragrande maggioranza del codice Go fa quello. </div><div>Personalmente, trovo sensato nella gran parte dei casi. Trovo che in altri casi sia piu' sensato gestire gli errori tramite callback, o per lo meno, progettare l'API in quella maniera. Poi chiaro come il sole che diventa tutto piu' complesso.</div><div><br></div><div>Detto poi fra noi, fra la gestione degli errori di Python non so quale mi piace di piu'. Devo cominciare ad avere roba in Go che fallisce male per entrare davvero in mentalita'. Ovvero... in C la mancanza delle eccezioni la sento tantissimo. In Haskell (che pure le ha, sebbene in generale non sia idiomatico usarle come si farebbe in Python) ci sono stati casi in cui le avrei volute. In Go per ora no... ma non e' che mi sia chiaro perche' non mi manchi. Credo che sia perche' ho scritto davvero troppo poco codice e non mi sono ancora rotto le palle di fare a mano cose che con le eccezioni avrei gratis.</div><div><br></div><div>Perche' voglio dire... potremmo scrivere intere librerie e framework in Python (per dire) con la convenzione di ritornare tuple per la roba che puo' fallire. Alla fine credo che non si faccia non solo perche' non e' la maniera di Python, ma sopratutto perche' spesso e' scomodo.</div><div><br></div><div>Io personalmente non trovo particolarmente carino qualcosa tipo</div><div><br></div><div>func doSomething() (res Result, err error) {</div><div>  op, err := operation1()</div><div>  if err != nil {</div><div>    return</div><div>  }</div><div>  mah, err := operation2(op)</div><div>  if err != nil {</div><div>     return </div><div>  }</div><div>  res, err := operation3(op, mah)</div><div>  return</div><div>}</div><div><br></div><div>rispetto a qualcosa come</div><div><br></div><div>def do_something():</div><div>    op = operation1()</div><div>    return operation3(op, operation2(op))</div><div><br></div><div>Sara' che mi devo ancora abituare...</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
> ed e' piuttosto accettabile. Ci sono momenti in cui vorrei avere<br>
> eccezioni vere e proprie, ma la cosa finisce li (si, so di panic, ma<br>
> la sintassi e' talmente orribile che mi sembra di fare piangere<br>
> gesubambino per niente).<br>
<br>
</span>"panic" non è inteso per essere usato come eccezione, e la sintassi<br>
scomoda è intenzionale. Non farlo, faresti piangere Rob Pike prima che<br>
Gesù bambino, e tu non vuoi questo, vero?<br></blockquote><div><br></div><div>Mi e' chiaro. La funzionalita' e' praticamente equivalente e hanno reso molto chiaro che gli hanno dato una sintassi brutta e scomoda per non incoraggiare. Poi detto fra noi, visto che Go schietto va di CSP e non di Actor model [0] non sarebbe particolarmente facile gestire le eccezioni che dovessero uscire dalle goroutine -- a meno di non ricostruirci sopra l'actor model --.</div></div><div><br></div><div>O meglio... non sono completamente d'accordo con "paninc non e' inteso per essere usato come eccezione". Nel senso che panic/defer/recover ti permetterebbero di costruire il classico error handling ad eccezioni. Quello su cui sono d'accordo e' che Go idiomatico non usa le eccezioni quando in altri linguaggi si userebbero, tutto li. </div><div><br></div><div>Alla fine nei vari linguaggi cambia tantissimo la pragmatica sull'uso delle eccezioni. Python e' sul lato dello spettro "le eccezioni per il normale controllo di flusso sono perfettamente normali e non sono particolarmente eccezionali", go e' sul lato opposto.</div><div><br></div><div>---</div><div>[0] non e' che parlo di impossibilita' effettiva, semplicemente il modello e' sufficientemente diverso da non rendere comoda sta faccenda, tipo linkare gli actors e avere il watcher che si suca le eccezioni del watched e ci fa cose... si puo' creare tutto con le goroutine, niente da dire, ma Go non e' concepito a quel modo e mi sta bene.</div><div><br></div><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>