<div dir="ltr">Si, <div>Grazie interessanti punti di vista. Il viaggio del apprendista stregone informatico inizia da consegnare:</div><div>1. codice bug free</div><div>2. codice bug free in qualsiasi condizione esterna.</div><div><br></div><div>In questo caso si han di fronte tre cose:</div><div>1.  Programmer  bugs </div><div>2. Errori recuperabili (soft error)</div><div>3. Errori non recuperabili.</div><div><br></div><div>Bene. La domanda e' siccome mi interessa la vostra esperienza, come gestite i punti 2, 3.</div><div>Saluti,</div><div>Giorgio.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 1 marzo 2015 00:32, Giovanni Porcari <span dir="ltr"><<a href="mailto:giovanni.porcari@softwell.it" target="_blank">giovanni.porcari@softwell.it</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Il giorno 28/feb/2015, alle ore 19:34, enrico franchi <<a href="mailto:enrico.franchi@gmail.com">enrico.franchi@gmail.com</a>> ha scritto:<br>
<div><div class="h5">><br>
><br>
><br>
> On Sat, Feb 28, 2015 at 2:06 PM, Giorgio Zoppi <<a href="mailto:giorgio.zoppi@gmail.com">giorgio.zoppi@gmail.com</a>> wrote:<br>
> Vorrei aprire una discussione senza cadere nella trappola del<br>
> expert beginner.<br>
> In Python in quali casi e' preferibile usare eccezzioni o in quali casi e' preferibile usare return codes. Secondo la teoria, spiegata in Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, :<br>
> "Exceptions integrate well with object-oriented languages. Object-oriented languages tend to impose constraints on member signatures that are not imposed by functions in non-OO languages. For example, in the case of constructors, operator overloads, and properties, the developer has no choice in the return value. For this reason, it is not possible to standardize on return-value-based error reporting for object-oriented frameworks. An error reporting method, such as exceptions, which is out of band of the method signature is the only option."<br>
><br>
> Ma ne la vita quotidiana si apprende dell'esperienza e non solo dalla teoria. Durante la vostra esperienza vi e' capitato di decidere questo?<br>
><br>
> Non capisco la domanda. Stai chiedendo se ho mai usato le eccezioni (si), se ho mai scritto codice che lancia intenzionalmente eccezioni (si), se ho mai scritto codice che non avrei potuto scrivere facilmente senza eccezioni (essenzialmente si) o quale sia la mia posizione a riguardo?<br>
><br>
> Come dire... boh. Dipende dal linguaggio e dipende dal contesto. Tipo in Java lavorare con le eccezioni pone limitazioni simili a lavorare "liberalmente" con i tipi di ritorno. Poi i tipi di ritorno hanno sempre il problema del valore nullo (controllare tutto per None e' in generale seccante, specie quando questo ti costringe a rendere None "invalido" perche' deve mostrarti l'errore -- in questo preferisco di gran lunga Maybe/Optional, che almeno funziona come si deve).<br>
><br>
> In Python la tradizione e' fare un uso abbastanza liberale delle eccezioni. Di per se si potrebbe avere anche la convenzione di ritornare *sempre* una tupla con qualcosa che indica l'errore. In Go si fa cosi' (o per lo meno, e' diffuso) ed e' piuttosto accettabile. Ci sono momenti in cui vorrei avere eccezioni vere e proprie, ma la cosa finisce li (si, so di panic, ma la sintassi e' talmente orribile che mi sembra di fare piangere gesubambino per niente).<br>
><br>
> In Haskell anche li le eccezioni ci sono, ma fino ad un certo punto. Trovo che non si integrino eccellentemente nel resto del linguaggio, per cui in generale tendo ad usare Maybe/Either. Alcune volte mi sono mancate. Ma sono secoli che non lavoro con Haskell.<br>
><br>
> Personalmente trovo che in un contesto imperativo/OOP le eccezioni siano proprio una gran cosa. Le proprieta' che hanno sul controllo di flusso sono spesso complicate da implementare altrimenti (o meglio, non complicate, solo un sacco di boilerplate). Poi ci sono i problemi accessori: seguire il controllo di flusso puo' diventare davvero un incubo, visto che diventa non predicibile manco sapere se qualcosa termina guardandolo.<br>
><br>
> def will_it_ever_end(a, b):<br>
>     while 1:<br>
>         a += b<br>
><br>
> Davvero non abbiamo modo di sapere cosa succedera'.<br>
><br>
><br>
><br>
><br>
<br>
</div></div>Ho già avuto modo di dire che sono solo un autodidatta sia pure di lunga data<br>
e quindi so che in questo momento rischio di dire fregnacce.<br>
<br>
Però mi sono sempre chiesto una cosa: siccome in python comunque tutto è un oggetto,<br>
non sarebbe in qualche modo plausibile rendere l'errore come attributo del risultato ?<br>
Se ad esempio scrivo x=f(y) allora posso poi testare x.__error__ per sapere se c'è stato un errore.<br>
<br>
Sono ragionevolmente certo che ci sia qualcosa di sbagliato in questo ragionamento ma<br>
sono troppo ignorante sulla parte teorica di python (o meglio in generale sui linguaggi)<br>
per capirlo. Enrico mi aiuti ?<br>
<br>
Ciao<br>
<span class="HOEnZb"><font color="#888888"><br>
G.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Python mailing list<br>
<a href="mailto:Python@lists.python.it">Python@lists.python.it</a><br>
<a href="http://lists.python.it/mailman/listinfo/python" target="_blank">http://lists.python.it/mailman/listinfo/python</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Quiero ser el rayo de sol que cada día te despierta<br>para hacerte respirar y vivir en me.<br>"Favola -Moda".</div>
</div>