Dotaz: PHP - funkce mi vrací undefined index

[pavele]

Mám takovou funkci v PHP, která funguje:

  public function addGet($no = null)
  {
    foreach( $_GET as $id => $value )
    { 
      if(!( $id == $no || $id == 'year'))
        $return .= '&' . $id . '=' . $value;
    }

    return $return;
  }

Ale v error_log mám:

PHP Notice: Undefined variable: return in /var/www/html/connect.php on line 388

Jak definovat/kontrolovat proměnnou v této funkci, aby se mi nezobrazovala tato chyba?

Díky.

---

---

Odpovědi

[00000]

  public function addGet($no = null)
  {
    $return = ''; // Tohle tu chybí

    foreach( $_GET as $id => $value )
    { 
      if(!( $id == $no || $id == 'year'))
        $return .= '&' . $id . '=' . $value; // To je jako "$return = $return . (zbytek);"
                                             // $return v první iteraci neexistuje
    }

    return $return;
  }

[trilobyte]

Před foreach dej řádek

$return = "";

Nechtěl bys raději použít funkci http_build_query()?

[pavele]

Díky moc, funguje.

Před chvílí jsem zkusil přidat řádek:

global $return;

a proměnnou jsem definoval na začátku souboru a fungovalo to.

Ale podle googlu se to moc lidem nelíbí a výše uvedené řešení je lepší.

Co se týče použití "http_build_query()" - nejsem programátor a nemluvím tvou řečí.

Pouze se snažím opravovat chyby /chybové hlášky/ v jednom programu po přechodu na PHP 5.4 (undefined index, undefined variable...).

A tím porušuji pravidlo - pokud to jede, tak na to nešahej. Tedy, testuju a hraji si s tím ve virtuálu, samozřejmě.

[Kit]

Tu funkci http_build_query() si snadno dohledáš v manuálu. Na rozdíl od té tvé funkce to udělá bezpečně.

Slovu "global" se vyhýbej na sto honů. Nedávej ho tam, nebo se zblázníš.

[pavele]

Díky, podívám se na to.

[AraxoN]

tyhle chyby nejsou způsobený přechodem na vyšší verzi php, už si je tam měl, jen se ti liší konfigurace (display_errors a/nebo error_reporting)

[AraxoN]

Áno, to čo hľadá je konfiguračný parameter "error_reporting" v súbore "php.ini".

Je to lepšie, než keď "neprogramátor" sa snaží opraviť kód, ktorý vyprodukoval "poloprogramátor" (súdiac podľa ukážky pôvodného kódu).

[Kit]

Změnou konfigurace error_reporting chyba nezmizí, pouze se přestane vypisovat. Pro začátečníka zcela nevhodná úprava konfigurace.

[AraxoN]

Áno, ale opravovať by to nemal niekto, kto o sebe hovorí "nejsem programátor". Niekto mu z recesie poradí rm-rf a bude na tom horšie než keď začal.

[pavele]

Pokud mi někdo z recese poradí rm -rf, klidně to pro legraci udělám.

Potom ovšem obnovím testovací kvm virtuál na mém firemním záložním serveru ze snapshotu a půjdu si hrát dál.

[AraxoN]

To som myslel obrazne. V programovaní je nekonečne veľa možností ako konkrétnu časť programu opraviť tak aby vyzerala správnejšie, ale zároveň neplánovane rozbila niečo na druhom konci programu. To sa môžeš dozvedieť o mesiac a nemusí byť zjavné, že to bolo týmto zásahom do kódu. Debugovanie a ladenie je ťažšie než písanie nového kódu. Nechal by som to na programátora.

Ak je cieľom program opraviť, potom Ti radia dobre, kde máš čo zmeniť. Ja si ale myslím, že cieľom je aby program išiel tak ako pred prechodom na novšie PHP a v tom prípade je lepšie naladiť error_reporting a opraviť len to, čo sa prechodom naozaj rozbilo. Táto konkrétna časť totiž bola rozbitá už pred prechodom.

[Kit]

Ještě jednou ne, změna error_reporting nic neřeší. Ta chyba tam byla ve starém PHP a zůstala tam. Je nezbytně nutné opravit tu chybu.

[Filip Jirsák]

Ona tam ta varování nebývají jen tak z rozmaru autorů. Ale třeba také proto, že se novější verze může začít chovat v dané situaci jinak. Takže to, že to mohlo být rozbité před přechodem na novou verzi PHP a fungovalo to, ještě neznamená, že to bude fungovat i po přechodu. Opravdu by se na ten kód měl podívat někdo, kdo chápe, co znamená, a kdo zároveň ví, co se změnilo v nové verzi PHP.

[AraxoN]

Ja s Vami obidvoma súhlasím. Akurát ten človek o sebe sám napísal, že nie je programátor. A preto je bezpečnejšie ak do kódu nebude šahať.

[Filip Jirsák]

Ne. Bezpečnější je, pokud do kódu bude sahat někdo, kdo kódu dokáže porozumět. Varianta nesahat do kódu vůbec je méně bezpečná, protože se s přechodem na novou verzi PHP může začít projevovat nějaká chyba, která se dříve neprojevovala.

[lolek]

bezpečnější bude, když přestaneš po internetu trousit ty svoje moudra, nikdo o ně nestojí

[Xerces]

Já bych se taky přikláněl v tomto případě to radši řešit změnou konfigurace pro vypisování stavových hlášek. Co když o kus dál v kódu je nějaké odchytávání except, kterým se ten stav ošetřuje a tím, že tady podstrčí prázdnou proměnou, tak to vlastně obejde. Ale pokud si věří, že to zvládne vše otestovat ve virtuálu, tak bych ho od zdokonalování kódu neodrazoval. Každej nějak začínal.

[Kit]

Například ve Wordpresu jsem našel podobnou chybu a ještě navíc s proměnnou "global". Stačilo jen ten global odstranit a aplikace začala fungovat jak má. Blokování warningů a noticek ničemu neprospívá.

[AraxoN]

A potom aktualizuješ wordpress a z upstreamu sa Ti tá chyba vráti. Môžeš ju takto opravovať znova a znova.

[pavlix]

Třeba ne.

[Kit]

To mě netrápilo, protože na svůj web bych si Wordpress nedal. Zákazník to chtěl spravit. Funguje to, hotovo.