<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-02-28 23:32 GMT+00:00 Giovanni Porcari <span dir="ltr"><<a href="mailto:giovanni.porcari@softwell.it" target="_blank">giovanni.porcari@softwell.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div><div>Un dettaglio che ti impedirebbe di farlo e' che determinati oggetti in Python *non* hanno attributi arbitrari.</div><div>Per esempio None. Non riusciresti ad attaccargli sopra x.__error__.</div><div><br></div><div>Questo e' un motivo "duro" per cui non si puo' fare. Ma ovviamente se si fosse voluto fare si sarebbe potuto dotare qualunque oggetto di un attributo __error__.</div><div><br></div><div>Sulla parte pratica, credo che alla fine dei conti scrivere</div><div><br></div><div>x = f()</div><div>if x.__error__:</div><div>    ...</div><div><br></div><div>non porti vantaggio rispetto ad altri modi di gestire l'errore. </div><div><br></div><div>Confronta con</div><div><br></div><div>res, error = f()</div><div>if error:</div><div>    ...</div><div><br></div><div>e vedi che non e' che sia una miglioria enorme.</div><div><br></div><div>Inoltre ci sono cose minori, tipo il fatto di dovere pagare sempre un puntatore (o analogo) per ogni oggetto (quindi un consumo di memoria non trascurabile), anche quelli che non ne avrebbero bisogno.</div><div> </div><div>Semmai la parte interessante potrebbe in qualche modo essere il concetto di auto-propagare l'errore. Ovvero l'idea e' che se hai un __error__ in entrata fai uscire qualcosa con un __error__. Questa strategia avrebbe comunque due problemi abbastanza massicci:</div><div><br></div><div>1. e' terribilmente implicita. temo si finirebbe con un problema che alla fine ha un __error__ e non si sa perche' (a meno di non avere una strategia molto complicata e molto costosa per "accumulare" gli errori</div><div><br></div><div>2. in generale se hai un errore non sei in grado di darmi un oggetto che abbia una parvenza di significato e appiccicargli __error__ non migliora troppo le cose.</div><div><br></div><div>Mi spiego... se mi fai un metodo che ritorna una lista, mi ritorni una lista vuota con __error__ e la cosa funziona (mi distingue il caso in cui la lista vuota e' il vero ritorno e mi costruisci un valore valido del tipo che vuoi ritornare).</div><div><br></div><div>Ma ci sono tipi che non hanno una "lista vuota". Che so... un libro. Che facciamo il "libro vuoto"? Cioe', in teoria si potrebbe creare un linguaggio che funziona cosi'... alla fine dei conti si chiama NullObjectPattern (meno il __error__) e in determinate circostanze e' buono.</div></div><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>