try catch ... ma ha senso con le funzioni native?

[nourdine]

ciao

volevo un paio di conferme sull'uso di try catch.

Il 99% delle funzioni native non fa il throw di errori giusto? il che rende non molto sensato l'uso di try catch no? per esempio si dia un'occhio a questa funzione:

function open_file($filename) {   
   try {
      $fp = @fopen($filename, "r");
      if (!$fp) {
         throw new Exception("errore gestito a mano");
      }      
   }
   catch (Exception $e) {
      fopen("default.txt");   
   }
} 

mi tocca lo stesso fare tutti gli if per vedere che valore booleano mi restituisce fopen, il che e' un po' quello che uno vorrebbe evitare con il paradigma try catch

sono aperte le danze

grazie

[Enoa]

Se usi "@" fopen non darà nessun errore, serve proprio a questo
http://www.php.net/manual/en/languag...rorcontrol.php

[nourdine]

ah si?

ma l'hai provato almeno? e secondo te

throw new Exception("errore gestito a mano"); 

a cosa serve??

qualcun'altro per favore?

[andr3a]

Originariamente inviato da nourdine
Il 99% delle funzioni native non fa il throw di errori giusto?

puoi settare un error handler che al suo interno farà un throw per te

$old_handler = set_error_handler(create_function('', 'throw new Exception("errore php");')); 

[nourdine]

Originariamente inviato da andr3a
puoi settare un error handler che al suo interno farà un throw per te

$old_handler = set_error_handler(create_function('', 'throw new Exception("errore php");')); 

good boy good boy

ecco la risposta che volevo sentire.

grazie

[lloyd27]

Il costrutto try-catch, e più in generale le eccezioni, non sono pensate per l'uso che pensi tu in questo caso..

Giusto per fare un esempio, su un progetto recente sul quale sto ancora lavorando, utilizzo le eccezioni nel caso di pagina 404. Ho un front controller che controlla la richiesta, e nel caso non corrisponda a nessuna risorsa, genera un eccezione di tipo Error404Exception (una classe derivata da Exception). Più in alto nello stack di funzioni, qualcun'altra sarà dentro ad un try, che si accorgerà dell'eccezione e si occuperà di tutto.

In linea di massima le eccezioni non sono state inserite (purtroppo) per gestire le funzioni più o meno native di php, ma per fornire uno strumento al programmatore per controllare il workflow della sua applicazione.. Spero di essermi spiegato..

[nourdine]

Originariamente inviato da lloyd27
Il costrutto try-catch, e più in generale le eccezioni, non sono pensate per l'uso che pensi tu in questo caso...

ah no? ma pensa te che pensavo di avere ragione ;-)

Ecco com'è la storia. try è fatto apposta per "provare" un pezzo di codice. catch per "catturare" qualche cosa. cosa? beh ... un'eccezione, ovvero un errore emerso in try. In java una cosa analoga a questa funziona:

try {
   int x = 5;
   int y = 0;
   int buggy = x/y;
}
catch (ArithmeticException e) {
   System.out.print("shut the fuck up"); // funziona come dovrebbe!
}

cioè l'errore viene zittito, e viene eseguito il blocco catch senza tante teghe. Insomma le eccezzioni vengono usate in java "per lo scopo che penso io".

Persino JavaScript la fa da maestro. Ecco il codice:

try {
   nonEsiste();
}
catch (e) {
   alert("error man") // error man
}

che funziona appunto alla grande.

in php invece ti tocca fare (grazie andr3a):

set_error_handler(create_function('', 'throw new Exception("errore php");')); // <<<< va che roba!!
try {
   $buggy = 5/0;
}
catch (Exception $e) {
   echo "shut the fuck up";
} 

nel fantastico mondo di php, si ha che l'errore non genera nessuna eccezione e il motore se ne esce con uno degli inutili e ingestibili messaggi di cui sapete.

Nessuna scusa dunque. Che alla zend si siano sentiti in colpa lo dimostra quando detto da andr3a nel reply precedente al tuo. Come sempre ci hanno messo una pezza. cioè ti fanno parlare a te con il gestore di errori per dirgli di buttare ecezzioni invece degli idiotici messaggi a cui siamo abituati.

Sarebbe ora che dessero una piallata a questi difetti. Per quanto riguarda le retrocompatibilità la gente può usare gli interpreti vecchi. il target dovrebbe essere liberare i programmatori veri dalle porcherie del passato. senno facciamo la fine di perl (che tutto sommato tiene ancora botta).

p.s.: non vorrei dare l'impressione che non mi piace php ;-) lo trovo uno spasso!

[lloyd27]

..è il problema delle cose aggiunte in corsa..
Avrebbero dovuto riscrivere tutta la gigantesca libreria php per utilizzare le eccezioni, e sarebbe stato da matti

[nourdine]

Originariamente inviato da lloyd27
..è il problema delle cose aggiunte in corsa..
Avrebbero dovuto riscrivere tutta la gigantesca libreria php per utilizzare le eccezioni, e sarebbe stato da matti

si si capisco ... pero' vedi ... la roba che non capisco e' perche' non si impegnino seriamente nella creazione di un linguaggio di scripting che possa andare mainstream. la zend ha la fortuna/merito di avere una fetta di mercato niente male. se guardi le statistiche vedi che php e' uno dei linguaggi piu' usati al mondo (per il web). detto questo andrebberio prese dei provvedimenti seri. passi il dualismo linguaggio procedurale/linguaggio OOP; quello e' se vuoi un vantaggio. io parlo delle piccole migliaia di immense inconsistenze disperse ovunque nel linguaggio. ce ne sono veramente tante. mi stupisce che sia uscito un libro come "JavaScript the good parts" prima di "php the good parts" ... i programmatori php ne avrebbero veramente bisogno.

Nou

[lloyd27]

Stiamo andando un po OT, ma pazienda per stavolta..
Secondo me semplicemente la Zend se ne frega. Hanno troppo mercato con gli utilizzi PHP "casalinghi" per preoccuparsene..

Lo sviluppatore di basso profilo il sito non se lo fa mica in .NET o in Java, prende PHP, che nel lotto è il più immediato, e lo usa. Detto questo, Zend è conscia di gestire un linguaggio praticamente disastroso sotto migliaia di profili, però che attira la massa per la semplicità. Per questo non hanno interesse a migliorarlo davvero.. In fondo a loro cosa può interessare di avere una naming convenction assolutamente inesistente (basta vedere la la pagina del manuale con le funzioni delle stringhe), o una gestione degli errori praticamente ridicola..

E' la stessa cosa che ha fatto Microsoft con Windows. Hanno da sempre dominato il settore, ma negli ultimi anni tra linux e soprattutto mac qualcosa gli hanno rosicchiato.. Per cui hanno iniziato a ripensare il loro SO, con Vista (che per quanto disastroso può essere, un minimo di buona volonta per cambiare ce l'hanno messa) prima e soprattutto con 7 ora. PHP secondo me farà lo stesso, si arriverà ad un punto in cui la concorrenza sarà molto valida, ed anche per lo sviluppatore di basso profilo non sarà cosi automatico usare PHP.

A quel punto la Zend farà qualcosa, come ripensare il suo prodotto per ridargli un pò di appeal.. Questo ovviamente secondo me..