Si, Grazie interessanti punti di vista. Il viaggio del apprendista stregone informatico inizia da consegnare: 1. codice bug free 2. codice bug free in qualsiasi condizione esterna.
In questo caso si han di fronte tre cose: 1. Programmer bugs 2. Errori recuperabili (soft error) 3. Errori non recuperabili. Bene. La domanda e' siccome mi interessa la vostra esperienza, come gestite i punti 2, 3. Saluti, Giorgio. Il giorno 1 marzo 2015 00:32, Giovanni Porcari <giovanni.porc...@softwell.it > ha scritto: > > > Il giorno 28/feb/2015, alle ore 19:34, enrico franchi < > enrico.fran...@gmail.com> ha scritto: > > > > > > > > On Sat, Feb 28, 2015 at 2:06 PM, Giorgio Zoppi <giorgio.zo...@gmail.com> > wrote: > > Vorrei aprire una discussione senza cadere nella trappola del > > expert beginner. > > 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, : > > "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." > > > > Ma ne la vita quotidiana si apprende dell'esperienza e non solo dalla > teoria. Durante la vostra esperienza vi e' capitato di decidere questo? > > > > 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? > > > > 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). > > > > 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). > > > > 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. > > > > 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. > > > > def will_it_ever_end(a, b): > > while 1: > > a += b > > > > Davvero non abbiamo modo di sapere cosa succedera'. > > > > > > > > > > Ho già avuto modo di dire che sono solo un autodidatta sia pure di lunga > data > e quindi so che in questo momento rischio di dire fregnacce. > > Però mi sono sempre chiesto una cosa: siccome in python comunque tutto è > un oggetto, > non sarebbe in qualche modo plausibile rendere l'errore come attributo del > risultato ? > Se ad esempio scrivo x=f(y) allora posso poi testare x.__error__ per > sapere se c'è stato un errore. > > Sono ragionevolmente certo che ci sia qualcosa di sbagliato in questo > ragionamento ma > sono troppo ignorante sulla parte teorica di python (o meglio in generale > sui linguaggi) > per capirlo. Enrico mi aiuti ? > > Ciao > > G. > > > > > > _______________________________________________ > Python mailing list > Python@lists.python.it > http://lists.python.it/mailman/listinfo/python > -- Quiero ser el rayo de sol que cada día te despierta para hacerte respirar y vivir en me. "Favola -Moda".
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
