2012-11-06 12 views
11

tutto il web [1][2][3], si dice che dal PHP 5.0.0 "assegnando il valore di ritorno di nuovo per riferimento" dà un E_DEPRECATED o E_STRICT a seconda della versione di PHP (E_DEPRECATED non ha esistono fino al 5.3, quindi era E_STRICT prima).New di riferimento non dando avvertimento

Come tale è la mia comprensione che questo codice dovrebbe dare un avvertimento:

error_reporting(E_ALL | E_STRICT); 

class A 
{ 
} 

$a =& new A(); 

Tuttavia, ho provato questo su due server completamente diversi (uno in esecuzione di PHP 5.3 e uno in esecuzione di PHP 5.2) e non sta effettivamente dando un messaggio! Cosa sta succedendo? La mia comprensione è errata o c'è qualcosa di strano in questi due server?

(io anche che sia strano che questo è deprecato, visto che $a = null; $b =& $a; $b = new A(); non fa lo stesso di $a = null; $b =& $a; $b =& new A();, ma questa è solo una parte della questione, se ho capito male quello che è sconsigliato ...)

+0

Stranamente, ottengo questo errore solo se eseguo il comando su 'phpsh',' PHP Deprecato: l'assegnazione del valore di ritorno di new per riferimento è deprecata in /Library/Python/2.7/site-packages/phpsh/phpsh.php (578): eval() 'd codice on line 1', ma non se lo eseguo direttamente da cli. – Dogbert

+0

@Dogbert: È davvero strano. L'ho solo provato come servito da server Apache esterni, ma quando avrò il tempo cercherò di eseguirlo dalla riga di comando e 'phpsh' me stesso – Jasper

+1

Non mi sorprenderebbe affatto se il problema qui fosse altrove: prova a settare 'E_ALL | E_STRICT' nel php.ini direttamente, non dimenticare di cambiare anche php-cli.ini, se stai eseguendo questo codice sulla riga di comando. Controlla anche se gli errori non sono nascosti facendo un 'ini_set ('display_errors', 1);'. Inoltre, se stai eseguendo questo su una finestra di Windows, ci sono stati [alcuni bug] (https://bugs.php.net/bug.php?id = 46326) con questo in passato –

risposta

2

In risposta al PO, questo commento lo ha indirizzato nella giusta direzione:

Non mi sorprenderebbe affatto se il problema qui si trova altrove: provare a impostare E_ALL | E_STRICT nel tuo php.ini direttamente, non dimenticare di cambiare anche php-cli.ini, se stai eseguendo questo codice sulla riga di comando.
Controllare anche se gli errori non sono nascosti eseguendo un ini_set('display_errors',1);1. Se stai eseguendo questo su una finestra di Windows, ci sono stati some bugs con questo in passato.

Dal momento che l'OP ha anche sottolineato che gli avvertimenti sono stati generati prima ottenuto eseguito qualsiasi codice, ho avuto la sensazione, che gli avvertimenti previsti vengono sollevate al momento della compilazione, piuttosto che l'esecuzione, così ho avuto un altro sguardo a the docs. Lì, ho trovato questo grande rosso nota-box, che ha confermato i miei sospetti:

La maggior parte degli errori E_STRICT sono valutati al momento della compilazione in tal modo tali errori non vengono segnalati nel file in cui error_reporting è stata migliorata per includere errori E_STRICT (e viceversa).

A partire dalla versione 5 di PHP è effettivamente un "compilato" lingua (simile a Java, il codice viene compilato a Zend Bytecode). Quando il motore Zend compila il codice con errori emessi al momento della compilazione, una chiamata in-script error_reporting non ha alcun effetto sul tempo o non vengono segnalati questi errori: la chiamata error_reporting si applica solo agli errori/avvisi di runtime. error_reporting(E_ALL | E_STRICT | E_COMPILE_ERROR); Forse vale la pena dare un'occhiata anche a

Bottom line:
Impostare la segnalazione degli errori nei file php.ini ogni volta che è possibile.

+0

In effetti, il punto che gli errori vengono fatti prima che venga eseguito qualsiasi codice (che è un altro modo di dire in fase di compilazione) è una conclusione che ho tratto dal fatto che l'impostazione di "error_reporting" dallo script non ha funzionato e impostazione ha funzionato esternamente. Ovviamente anche il codice lo ha mostrato, ma a quel punto mi aspettavo che gli errori si sarebbero verificati al massimo se non fossero stati visualizzati. – Jasper

+0

@Jasper, ho pensato che tu conoscessi compile- vs runtime, ma non è qualcosa a cui tutti sono consapevoli, è per questo che ho incluso questa distinzione nella mia risposta, quindi questo è principalmente pensato per informare gli altri. Il tuo problema, come ormai sai fin troppo bene, era che il file .ini riguardava le impostazioni solo se il motore Zend dall'inizio alla fine, "error_reporting" sovrascrive quelle impostazioni solo dopo che il codice è stato compilato ed è pronto per correre. Ho solo pensato che non tutti avrebbero trovato quella risposta sufficiente ;-P ... comunque, bella domanda: ho scoperto un paio di cose nuove anche io, –

+1

È bene che tu l'abbia incluso nella tua risposta Di cosa stavo parlando, davvero. Ciò di cui stavo parlando era il fraseggio di "poiché anche l'OP ha sottolineato [..]". Sì, a volte posso essere pignolo. Ma non importa, è abbastanza vicino alla verità: D – Jasper

Problemi correlati