[Python] Python exception or return code.

[Massimiliano della Rovere]

Si pone però un problema in questo scenario:
dato che il risultato non può essere generato (a causa dell'errore), manca
qualcosa a cui agganciare il magic method __error__.

Una possibile soluzione a questo problema sono:
- i deferred di Twisted
https://twistedmatrix.com/documents/current/core/howto/defer.html

- i futures di Python 3.3+
https://docs.python.org/3/library/concurrent.futures.html#future-objects

- i future di tornado:
http://www.tornadoweb.org/en/stable/concurrent.html


(e in Javascript la libreria Q:
http://www.html.it/articoli/javascript-asincrono-le-promise-e-la-libreria-q/
)

Il giorno dom 1 mar 2015 alle ore 00:33 Giovanni Porcari <
giovanni.porcari a softwell.it> ha scritto:

>
> > Il giorno 28/feb/2015, alle ore 19:34, enrico franchi <
> enrico.franchi a gmail.com> ha scritto:
> >
> >
> >
> > On Sat, Feb 28, 2015 at 2:06 PM, Giorgio Zoppi <giorgio.zoppi a 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 a lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150228/00a07a45/attachment-0001.html>