[Python] Python exception or return code.

[enrico franchi]

2015-03-01 0:12 GMT+00:00 Giorgio Zoppi <giorgio.zoppi a gmail.com>:

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

Io direi che qui terminerebbe, ammesso che ci si arrivasse mai. Salvo che
le due condizioni sono equivalenti (se non hai bachi, non hai bachi manco
in condizioni estreme; se hai bachi che si manifestano solo in condizioni
estreme, vuole dire che comunque hai bachi). Mi sembra un po' una vana
speranza: codice *senza* bachi sopra una certa dimensione non e' che ne
veda molto.

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

La classificazione che proponi non mi fa impazzire troppo (nel senso che e'
molto difficile separare i punti 2 e 3 a priori... mentre e' relativamente
chiaro come funziona a posteriori).

Faccio un esempio: devo parlare con un servizio. Allora vado a risolvere il
nome sul DNS. Non ho risposta. Cosa e'? Non ho modo di saperlo.
Probabilmente voglio una strategia di retry; se qualcuno si era mangiato il
mio pacchetto UDP per caso, probabilmente avro' risposta. Mi sembra un
esempio di errore recuperabile. Se invece tutta l'infrastruttura del DNS ha
preso fuoco e sta malamente capitolando... diciamo che probabilmente sto
per fronteggiare un fallimento totale. Ma ancora... non e' chiaramente un
bug (non nel mio software); e' un fallimento esterno.

Diciamo che in generale quando sono in una condizione che non posso
recuperare dentro l'applicativo quello che faccio e' fare in modo che le
cose vengano escalate ad un umano (allarmi, ticket). Il resto quando
possibile cerco di recuperarlo. Ma anche li... fare il retry di ogni
chiamata ad un servizio fallita (seguendo la semantica HTTP) non e' sempre
la cosa giusta. A volte e' meglio semplicemente fare fallire la chiamata di
piu' alto livello e l'utente provera' a ricaricare, il motivo e' che
altrimenti comunque la risposta all'utente e' troppo lenta (e c'e' caso che
provera' a ricaricare comunque, con conseguenze consumo di risorse),
inoltre rischia di sovraccaricare la rete e/o i servizi accessori. In altri
casi il retry e' un salva vita. Poi ci sono casi in cui non ha senso.

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