Silenziare un foreach

[Graboid]

Ciao,

ho un foreach che ha volte da errori perche' manca un record a db (ho stretto perche' non e' fondamentale).

$artist_data = $Artists->get_artist_data($id);
    @foreach($artist_data as $key=>$value){
        $artist_data[$key] = $Utility->mysql_clean_data($value);
} 

Volevo silenziarlo con l'operatore @ ma è come se il codice ignorasse la @.
Qualche idea?

[dadepax]

non sarebbe meglio fare un controllo sul risultato della query da db???


if($ris==0){
fai qlc
}else{
inserisci il foreach
}


Io di solito faccio così

[Graboid]

Direi che sarebbe piu' facile ma piu' dispendiosa, non migliore.
La soluzione di seguito dovrebbe almeno farti risparmiare la query:

if(sizeof($artist_data) != 0){ // sipresume quindi che sia popolato
 foreach($artist_data as $key=>$value){
        $artist_data[$key] = $Utility->mysql_clean_data($value);
   }
} 

Cmo lo tengo come ultimo tentativo, senza tener conto che probabilmente l'errore non verra' stamapato a video quando il sito sara' uploadato visto che , almeno si spera, il provider avra' settato correttamente l'error reporting.

Cmq resta che il fatto che pensavo che l'operatore di silence potesse venir usato dovunque ela cosa mi incuriosisce.

Grazie cmq dell'aiuto

[FinalFantasy]

la soluzione di dadepax è la migliore e, secondo me, + sicura...ki ti sa dire meglio il numero di risultati: php o mysql? io opterei x la seconda, cioè cn un mysql_numrows sn sicuro...

if (mysql_numrows($query)>0)
{
//esegui il ciclo
}

[whisher]

Ciao.

Cmo lo tengo come ultimo tentativo, senza tener conto che probabilmente l'errore non verra' stamapato a video quando il sito sara' uploadato visto che , almeno si spera, il provider avra' settato correttamente l'error reporting.

Non è un bel modo di sviluppare !

[andr3a]

Originariamente inviato da Graboid
il provider avra' settato correttamente l'error reporting.

il settaggio corretto per l'error reporting è E_ALL ... tutto il resto che si basa sul fatto che non ci sia un E_ALL è scritto presumibilmente male ed è potenzialmente problematico/non ottimizzato/poco sicuro.

I controlli vanno fatti sempre, soprattutto quando i dati vengono da un db o arrivano in esso

[Graboid]

Ma scusate secondo voi in un hosting non andrebbero tolti tutti warning etc.. etc che possono sporcare la pagine?
E_ALL in produzione non mi sembra proprio una buona idea.

Ho mai scritto che non faccio i controlli perche' tanto chissenefrega in produzione non verranno stampati?

Che significa non mi sembra un bel modo di programmare wisher? Non capisco bene a cosa ti riferisci.

Cmq non mi avete ancora convinto a usare quella query in piu' .


P.S.: nessuno ne ha piu' parlato ma do per scontato che un foreach non si possa silenziare? E quindi l'operatore di silence lo posso usare solo per....

[andr3a]

Originariamente inviato da Graboid
Ma scusate secondo voi in un hosting non andrebbero tolti tutti warning etc.. etc che possono sporcare la pagine?

non dovrebbero esserci messaggi in grado di sporcare le pagine, è questo il punto ... se ci sono, qualcosa è stato scritto male o qualcosa non è stato controllato al meglio

Originariamente inviato da Graboid
E_ALL in produzione non mi sembra proprio una buona idea.

per questo tanti scripts sono stracolmi di buchi ... con C# mica puoi usare variabili a caso, se lo fai o se non fai i dovuti controlli il server va in errore e mostra "tutto".

C# è un linguaggio di programmazione, ha pseudo compilazione e velocità nonchè strict rigoroso in stesura, PHP è anche per quelli a digiuno totale ... ma non per questo ci si deve basare sul fatto che Notice o Warning non sia problema, semplicemente non devono esserci quindi i controlli vanno fatti tanto quanto un linguaggio un pò più serio ... almeno quelli più importanti (per me tutti ma almeno quelli da e verso il db)

Originariamente inviato da Graboid
Ho mai scritto che non faccio i controlli perche' tanto chissenefrega in produzione non verranno stampati?

probabilmente l'errore non verra' stamapato a video quando il sito sara' uploadato visto che , almeno si spera, il provider avra' settato correttamente l'error reporting.

Originariamente inviato da Graboid
Che significa non mi sembra un bel modo di programmare wisher? Non capisco bene a cosa ti riferisci.

significa fai i giusti controlli e non basarti sul settaggio dell'error_reporting, se poi cambiano settaggi sul server fai una figura barbina

Originariamente inviato da Graboid
Cmq non mi avete ancora convinto a usare quella query in piu' .

nessuno ti ha detto di usare una query in più, se usi mysql_query ed usi mysql_num_rows non fai mica una query in più ... usi solo una funzione MySQL

Originariamente inviato da Graboid
P.S.: nessuno ne ha piu' parlato ma do per scontato che un foreach non si possa silenziare? E quindi l'operatore di silence lo posso usare solo per....

foreach(@$artist_data as $key=>$value){ ...
credo basti questo ... ma
1 - non è un modo corretto di sviluppare in php
2 - usare @ è, nel 90% dei casi, un errore ... questo caso rientra nel 90%, dato che hai una semplice e pulita alternativa, num_rows

[Graboid]

foreach(@$artist_data as $key=>$value) non funge cmq mi avete convinto sull'uso di @ o meglio sul suo non uso. Ammetto che avevo pensato che mysql_num_rows fosse come fare un altra query .

probabilmente l'errore non verra' stamapato a video quando il sito sara' uploadato visto che , almeno si spera, il provider avra' settato correttamente l'error reporting.

Certo che pero' prendere le frasi a metà puo' cambiare di molto il senso della frase stessa.
Il: "senza tener conto che" dove lo lasci? (di secondo lavoro fai il giornalista? (non prendertela sto solo scherzando))

grazie dell'aiuto

[piero.mac]

non entro nella "polemica" solo affermo che l'operatore @ di controllo errori non funziona con foreach, come d'altronde' eì ben specificato dal manuale.

http://it.php.net/manual/it/control-...es.foreach.php






Pensiero del giorno. Anche se metto delle calze pulite sui piedi sporchi, l piedi continuano a puzzare.