<div class="gmail_quote">2011/12/7 Carlos Catucci <span dir="ltr"><<a href="mailto:carlos.catucci@gmail.com">carlos.catucci@gmail.com</a>></span> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>

<div>Avrebbe senso gestire che non esiste un programma esterno che usi, come  "/bin/df" quando fa parte sia dello standard POSIX e il tuo programma deve girare solo su Linux?</div></div></blockquote></div><div>

<br>Stai elencando un caso limite. </div></div></blockquote><div><br></div><div><div>È un caso che mi è capitato nel progetto trash-cli.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div>Comunque se scrivo in PHP p Python o altro linguaggio multipiattaforma che debba girare su piattafroma linux e basta non e' detto. DOmani magari il clinete mi cambia con win.<br></div></div>

</blockquote><div><br></div><div>Non è mai detto. Per come la vedo io non è detto neanche che esista quel domani in cui si va su Windows.</div><div>La soluzione che adotto io implementando solo quello che serve oggi sforzandomi per ottenere un design flessibile (senza duplicazione e robusto) che posso estendere in futuro.</div>

<div>Non mi va di far pagare al cliente oggi quello che potrebbe in teoria servirgli domani.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">

<div>

 <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Alcune eccezioni che sono difficili da prevedere le puoi prevedere (il disco diventa readonly per una inconsistenza a metà esecuzione del tuo script). Io non penso che sia il caso di gestirle, anche perché se non posso prevederle non posso prevedere una strategia per gestirle. Certo posso mettere un try catch generico ma gestirle vuole dire anche aggiungere un comportamento ragionevole in caso di errore.<br clear="all">



</div></div></blockquote></div><div><br>Chiaro che non puoi prevedere tutto, ma se scrivo un pezo di codice che fa cose lo metto tra Try Eccept, non costa molto e mi garantisce che al peggio un pass evita di mostrare l'errore al final monkey .... ehm  user<br>

</div></div></blockquote><div><br></div><div>Anche in questo caso dipende. Se devo fare un prodotto per un certo tipo di utenza ci metto un try/catch generico che salva i dettagli dell'eccezione in modo che possano essere spediti a me facilemnte. Se devo fare un prodotto per un'altro tipo di utenza, e magari CLI, metto quante più possibili informazioni sull'eccezione e stampo lo stack trace ed esco.</div>

<div><br></div><div>Ciao</div></div><br clear="all"><div><br></div>-- <br>Andrea Francia <a href="http://www.andreafrancia.it" target="_blank">http://www.andreafrancia.it</a><br>