operatore di silence, ci sono motivi per utilizzarlo ?

[JVM]

ciao, ho letto questo topic, la domanda è: non lo utilizzate mai nei vostri script ? A me non capita mai, ma ci sono casi in cui è meglio utilizzarlo ? Voi che ne dite ?

[-AA-]

come dice il post
meno lo usi meglio è

non credo ci siano buoni motivi per nascondere gli errori di programmazione...

[Marcolino's]

La seconda che -AA- ha detto!
Credo sinceramente di non averlo mai usato, se lo usi non sai se, quando e perché si verifica un dato errore, anche (e soprattutto) in una procedura ben testata e a prova di errore (e a questo punto che lo usi a fare?) comunque per citare una nota legge di murphy, se una cosa può andar male sicuramente lo farà, ergo, al suo posto preferisco usare delle noiose procedure di controllo dell'errore che però mi danno più sicurezza.

[Santino83_02]

gli errori vanno intercettati, non ignorati a prescindere... al più li ignori quando li intercetti

[Marcolino's]

Scusa perché ignorarli?

[Grino]

Come dice Santino gli errori vanno intercettati e gestiti. Di norma un sistema di produzione non visualizza gli errori generati da PHP, dato che si preferisce indirizzarli verso un file di log. Ma questo potrebbe non essere sempre vero.

Quindi si potrebbe desiderare generare dei messaggi d'errore amichevoli per l'utente finale, integrandoli all'interno della pagina che si produce, evitando l'assenza del messaggio nei sistemi di produzione o l'apparire di orripilanti scritte che non dicono nulla all'utente finale, alterando per altro l'aspetto finale della pagina.

Esistono delle funzioni che producono dei messaggi d'errore, e non per un errore di programmazione, ma semplicemente perchè una risorsa potrebbe non essere disponibile. Queste funzioni in caso di errore ritornano null o false. Ad esempio MySQL potrebbe essere giù, e anche la chiamata procedurale di connessione produce l'apparire del messaggio improponibile all'utente. A questo punto si hanno varie possibilità come l'utilizzo della funzione set_error_handler, che deve ritornare false altrimenti parte anche la gestione da parte di php, o bypassare la gestione con la @ e far seguire la funzione che potrebbe produrre l'errore da un or e la funzione che gestisce la situazione anomala.

esempio:

...
if (!(self::$conn = @mysql_connect($sf_app->IniGet(cDB::kSF_HOST), $sf_app->IniGet(cDB::kSF_USER), $sf_app->IniGet(cDB::kSF_PASS))))
                    throw new cErroreFramework(stupidoframe::FraseGet('sf_db_ImpossibileConnettersi'));
...
catch (cErroreFramework $e) {
            echo $e;
            exit;
        } 

In questo modo in una mia applicazione, in servizio da un paio d'anni, ottengo che la pagina risultante sia anche in caso di errore una pagina xhtml perfettamente formattata e convalidata dagli strumenti automatici del W3C tanto in produzione quanto sul server di sviluppo mostrando all'utente un messaggio di errore più chiaro di quello che potrebbe fare PHP nei confronti di un utente comune.

Questo è il caso di MySQL, ma non è la sola risorsa che possiede funzioni che adottano un simile comportamento. Un altro esempio è fopen per il quale il manuale riporta:

Return Values

Returns a file pointer resource on success, or FALSE on error.

Report a bug
Errors/Exceptions

If the open fails, an error of level E_WARNING is generated. You may use @ to suppress this warning.

[JVM]

grazie ragazzi