[Python] Python exception or return code.

[enrico franchi]

2015-02-28 21:04 GMT+00:00 Nicola Larosa <nico a teknico.net>:

> Enrico Franchi wrote:
> > 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)
>
> No no, che diffuso, il modo è quello e basta, vedi blog ufficiale:
>
> Error handling and Go
> <http://blog.golang.org/error-handling-and-go>
>
> Defer, Panic, and Recover
> <http://blog.golang.org/defer-panic-and-recover>
>
> nonché l'autorevole Dave Cheney:
>
> Why Go gets exceptions right
> <http://dave.cheney.net/2012/01/18/why-go-gets-exceptions-right>
>

Il modo e' quello perche' la stragrande maggioranza del codice Go fa
quello.
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.

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.

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.

Io personalmente non trovo particolarmente carino qualcosa tipo

func doSomething() (res Result, err error) {
  op, err := operation1()
  if err != nil {
    return
  }
  mah, err := operation2(op)
  if err != nil {
     return
  }
  res, err := operation3(op, mah)
  return
}

rispetto a qualcosa come

def do_something():
    op = operation1()
    return operation3(op, operation2(op))

Sara' che mi devo ancora abituare...



>
> > 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).
>
> "panic" non è inteso per essere usato come eccezione, e la sintassi
> scomoda è intenzionale. Non farlo, faresti piangere Rob Pike prima che
> Gesù bambino, e tu non vuoi questo, vero?
>

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 --.

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.

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.

---
[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.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150228/d63d9ccc/attachment-0001.html>