Megadják a lehetőséget

Azt most már tudjuk, mi a szar, de a temérdek jobb, átláthatóbb, refaktorbarát alternatív javaslatot még nem találtam meg a hsz.-eidben.

Aki pedig azt állatja, hogy minden függvényt azzal kezd, hogy /** */, az biztos ráér programozni
Az annotáció pedig megkönnyíti a további fejlesztést, az autocomplete felhasználás során.
Mert meg sem kell nyitnod függvényt tartalmazó fájlt tudni fogod a be-ki-meneti paramétereket, típusukat és kivételeket, amit dobhat.
Ehelyett ha lehagyod, jobb esetben tízszer nyithatod a fájlt és böngészheted a függvényt, mit miként adj át és várj viszont. Utóbbi minden bizonnyal gyorsabb.

A tömbös indexes hibakezeléses megoldásos pedig aranyos, de ne akard már itt megmagyarázni, hogy ez a frankó, mert már nem tudom, hogy sírjak vagy nevessek.

[ Szerkesztve ]

- http://pazsitz.hu -

"Azt hiszem érthető voltam, de akkor leírom érthetőbben: amikor refaktorálod (átírod, javítod) a kódot, nem fogod tudni, hol dobtad az exceptiönt, amíg tényleg nem dobtál egyet.
Például van a form validáló osztályod, ami dobhat 4féle exception-t, te meg szeretnéd tudni, hol dobja, akkor legjobb esetben is ctrl+ffel keresel rá. Ha pedig a stacktrace-t akarod használni, ahhoz generálnod kell egy olyan hibát, ami ezt az exceptiont dobja."
Azt hiszem, én is érthető voltam, amikor leírtam, hogy egy általános jellegű Exception elkapásával minden kivételt el lehet kapni, és a kivétel keletkezésének módjáról mindent meg lehet tudni. Ha azt szeretnéd megtudni, hol dobja, és egész addig nem tudod, amíg nem keletkezett egy pontosan olyan specifikus hiba, akkor valóban az a megoldás létezik, hogy generálsz olyan hibát, vagy rákeresel. És? Nem értem a logikádat, ez miben tér el attól, ha te mondjuk ragaszkodsz a hibatömbös megoldásodhoz. Ha a hibatömbös hibakezelés forrásaira szeretnél rátalálni, akkor még a klasszikus exceptionökre vonatkozó backtrace-es megoldás sem áll a rendelkezésedre, de szerencsére mivel a PHP elég kényelmes nyelv, még erre is igénybe lehet venni egy plusz segítséget (kicsit mintha a bal kezeddel vakarnád meg a jobb füledet a tarkód mögül): debug_backtrace().
Még egy dolog: ha definiálsz saját exception osztályokat, akkor azoknak többnyire elég normális, egyedi neve van.
Pl. legyen épp ValidationException a neve.
Mondjuk ennek eldobása egy egyszerű globális fv.-en belül így néz ki:

function blabla(){
// .......
if( $hiba_van ){
throw new ValidationException( 'ezért meg azért' );
}
// .......
}

a Te megoldásod meg valami ehhez hasonló:

function blabla(){
// .......
if( $hiba_van ){
$errorArray['status'] = FALSE;
$errorArray['msg'] = 'ezért meg azért';
return $errorArray;
}
// .......
}

Ha már Te mindenhol az ugyanilyen jellegű hibatömbös megoldást alkalmazod, és Ctrl+F-es módszer, akkor szerintem több esély van gyorsan megtalálni a throw new ValidationException részt.
De a tömbös megoldást továbbra sem kínál beépítetten backtrace megoldást.

"Nyilván, ha valaki idiótán programoz, arra nincsen mentség."
Ez önmagában igaz. De arra, amire reagáltál, ez valahogy kicsit sántít. Pl. ha már újrafelhasználásról beszélünk, nem tudom, valakinek miért kellene kitalálnia, hogy a kódot elkészítő illető pontosan milyen tömbindexeket használt. Ja, hát nézze át az egész kódot, ha már szar a dokumentáció, hisz' bár a függvényt készítő ember nem ért rá odaírni három sort, ha három kivételt dob a fv. elejére, de a kódot felhasználó illető majd nyilván rá fog érni átnézni a komplett kódot. Itt pedig ez az indexeléses módszer nem biztos, hogy olyan intuitív megoldás, hogy ránézésre, már az első példa láttán lehet tudni, hogy mi is a helyzet többféle alkalmazásnál.

Sk8erPeter

én inkább így közelíteném meg:

function blabla(){
// .......
$errorArray = array();
if( $hiba_van ){
$errorArray[] = 'ezért meg azért';
return $errorArray;
}

return empty($errorArray) ? true : $errorArray ;
// .......
}

Az exceptiondobálós példával van még egy gubanc: ha minden egyes alkalommal, amikor hibát találsz a validációban, dobsz egy kivételt, akkor ki fogod hagyni az utána következő formelemek validálását, és nem fogod tudni, van-e több hiba is.

Ha pedig minden formelemen végigmész, összegyűjtöd a hibákat, és utána dobsz egy exception-t, benne például egy tömbbel a hibákról, akkor már nem nagyon látom annyira egyszerűbbnek a hibakezelést.

Ez sajnos nem volt egy túlzottan érdemi reakció.
Pl. miután kijelentetted, hogy nem igazán tudsz olyan frameworkről, ami exceptionökre építené a működését, megmutattam a Symfony-t, mert próbáltam érdemben vitatkozni, nem csak általánosságban beszélni. A Symfonynál meg most hirtelen nem tudom, milyen meggyőzőbb frameworköt kellene neked mutatnom, hogy az exceptionök létjogosultsága valamennyire világosabbá váljon.

Egyébként a gyakorlati ellenpéldákat én is hiányolom, ha már kritizálod azoknak a programozási szokásait, akik a kivételek használatára építenek. Azt érezteted, hogy a kivételekre építés rossz programozói gyakorlat (tehát valamit rosszul csinál az, aki erre alapozva kezeli a program menetében felmerülő hibákat), miközben nálunk okosabb emberek komplett keretrendszert építettek erre. Én jobban hajlanék az érveid elfogadására, ha alátámasztanád őket konkrét példákkal - attól függetlenül, hogy "minden probléma egyedi". Igen, a formvalidálás problémája is egyedi, meg az is, hogy hogyan kezelj le egy 404-es hibát. Én mindkettőre elmondtam a saját megoldásom (privátban komplett pszeudokódot is mutattam, ezt alátámasztandó), úgy tűnt, belátod az átláthatóság előnyeit kivételkezelésnél. De saját példát is mutathatnál, mert én nyitott vagyok más megoldásokra, ha az érdemi javulást hozhat a kódban.

Ha valaki vitatkozik az álláspontoddal, nem azért teszi, mert feltételezi, hogy hülyeségeket beszélsz, épp az a jó szakmai vita ismertetőjele, hogy szakmai szempontokkal győzzük meg egymást (én erre törekszem), nem pedig bezárkózásunknak adunk jelet.

A magasabb szintű programozói nyelvekben meg a kivételkezelés nagyon nem ördögtől való.

Kicsit számomra is olyan ez a vita, mintha arról beszélnénk, hogy mennyire nem éri meg objektumorientáltan programozni, mert az akár lassulást is hozhat. Ugyanez igaz C++-ra is: az OOP-s megoldás továbbra is lassabb marad, ezzel nyilván nem mondtam újat.
De ettől még megkérdőjelezni az OOP előnyeit nem érdemes, mert tény, hogy az átláthatóságban, követhetőségben, az objektumok logikai összetartozásában, kapcsolódásában, annak szemléltetésében, az emberi gondolkodáshoz való hasonlóságában, stb. annyi előnye van, ami miatt bőven van létjogosultsága (ez sem új, de elmondom).
Ettől függetlenül mégis hosszas érvek vannak, amik miatt pl. a Drupal még mindig nem állt át a teljes objektumorientáltságra: Drupal programming from an object-oriented perspective. De ennek nagyon sok történelmi gyökere is van (PHP 4 miatti kompatibilitás - most már erre nem terveznek).

Sk8erPeter

A symfony error handlingről beszélt, ami tipikus hiba eset (értsd: ha hiba történik, amire egyáltalán nem számítottál, exception, ugyanez a Kohana is, ezért van stacktrace, amikor valamit elszúrok), nem arról, hogy a mindennapi funkcionalitást exceptionökre építed.

A 404-es hiba exceptionnel történő kezelése pedig nem ördögtől való, mint azt korábban írtam: mindegy. Viszont ez architektúrális szinten jelenik meg, ezért van létjogosultsága.

Mondtam, nehéz eldönteni mi az amit lehet/szabad/érdemes exceptionokkel csinálni és mi az, amit nem. A validálás olyan, amit én nem exceptiönökkel csinálnék. Alternatívát a 404-re pedig írtam.

Veled értek egyet, nem jó hozzáállás, ha mindenhol kiviteleket hajigálunk, egyszerűen nem erre lettek kitalálva, de ezt mutatja a nevük is. Például validáció során nem jelent kivételt az, ha invalid egy adat.

Igen, és itt aztán a visszatérési értéket megint csak vizsgálni kell, és akkor visszajutottunk ugyanoda, ahonnan elindultunk.

Vegyük azt a megközelítést, amit Te mondasz, tök egyszerű példával. Itt beletettem még annyit, hogy két különböző paraméterrel hívom meg a logErrors függvényt, ez is szándékosan jó butított példa. A syntax highlighting miatt inkább felraktam pastebinre:
http://pastebin.com/KxH2Fmk9

Na, akkor vegyük azt a megközelítést, amiről én beszélek (bár privátban hasonló jellegű megoldást mutattam), aktualizálva a példához:
http://pastebin.com/PVKe4uNA

Nem tudom, ki hogy van vele, de nekem a második, háromsoros kód jobban áttekinthető. A korábbiaknál meg annyi van bent pluszban, hogy van két saját kivételosztály, ami tömböt is tud fogadni.

(#9007) modder : azzal egyetértek, hogy nem mindig egyértelmű, mire szabad/érdemes exceptiont használni. De pl. egy form injection probléma tipikusan olyan, ami miatt érdemes lehet exceptiont dobálni. Ahogy egy adatbázis-kapcsolódás is.
A 404-es hiba meg ilyen alapon ugyanúgy gyakran előfordulhat, ha valaki elcseszi a keresett URL-t, esetleg van hivatkozás Google-ön keresztül olyan oldalra, amit azóta már töröltek, vagy magán az oldalon van rossz hivatkozás van; de tulajdonképpen ezt is meg lehetne oldani sima error tömbökkel, ahogy az összes többi hibát is. Tulajdonképpen mindkettő megoldás alkalmazható minden problémára, kérdés, mire melyiket érdemes - bár az valóban érdekes felmérés lehet, mennyit ront a GYAKORLATBAN a teljesítményen az, ha valaki exceptionökre áll rá.
Ha valaki tud ilyen felmérésről, ne tartsa magában!

===

(#9008) Athlon64+ : nem is kell "mindenhol" kivételeket hajigálni.

[ Szerkesztve ]

Sk8erPeter

Hogy lehet egy model értékeit dinamikusan használni?
Adott az adatbázisban pár ilyen bejegyzés:
nap_1, nap_2....nap_x
Ezeket akarom nem egyesével, valami tömbben feldolgozni, konkrétan egy explode-ot szeretnék az adott adatokban.
Így próbáltam, de...

$model->'nap_'.$i;
//meg így is
$napok=array('nap_1'.....);
$model->$napok[$i];

Egyikkel sem akar menni, biztos van rá valami, de ...

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

"felmérés" helyett inkább simán teljesítménymérésre gondoltam.

(#9010) Speeedfire : bárcsak közérthetőbben írtad volna le, mit szeretnél.

[ Szerkesztve ]

Sk8erPeter

Ez így objektum hívás?

$model->'nap_'.$i;

Konkrétan nem értelek. Most kiveszed adatbázisból a nap_xy bejegyzéseket és belerakod egy tömbbe majd mindre ugyanazt a feldolgozást ráhúzni?

foreach?

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Igen és igen.
Rosszul declaráltam valamit azért nem ment, de már okés.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Nem akartam amellett kardoskodni, hogy kb soha nem szabad Exceptionöket használni, csak nem érdemes első megoldásként gondolni rá. Mindig nagyban függ a problémától, lehet, hogy nagyobb cégeknél, pl. IBM erről vannak infók. Én úgy érzem, hogy nem szívesen fordulok Exceptionökhöz, mégha kényelmesnek is tűnik a használata.

Erről lehetne akár cikket is írni, hogy hogyan lehet bizonyos eseteket simán return valuekkal vagy exceptionokkel megoldani, és összehasonlítani.

Két nagy probéma van az exceptionökkel:

C++-ban azért okoz teljesítméncsökkenést, mert az Exception-t a stacken hozza létre, és dobásnál ahogy visszatér az összes függvényből, mindig a stack tetejére kell másolnia az exception objektumot, ha a catch 5 fv-nyel föntebb van, akkor az 5 másolás.

A másik probléma pedig hogy ha például nyitunk egy resource-t pl file handlert, de dobunk egy exception-t, akkor hajlamosak vagyunk erről megfeledkezni, és nyitva marad.

Az előbbi szerintem PHP-ra már nem igaz, mert amúgy minden adatstruktúrának megvan a C-beli reprezentációja (plusz absztrakció), egyébként pedig valszeg minden heap-en van tárolva.
utóbbi pedig akár lehet igaz is.

Valahogy le lehet kérdezni egy gomb adatait?
2 submit gombom van, ha az egyikre kattint akkor feltölti az adatokat, ha a másikra akkor pedig tovább lép egy másik oldalra.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

name és value attributumát megkapod php-ban

Na ja. Asszem így már nagyjából összeért az álláspontunk. Csak kár, hogy eddig is PHP-ról beszéltünk (nem C-ről és nem is C++-ról), így egy kis időt megspórolhattunk volna.

Miután legalább egy órát elb@sztam azzal, hogy a kivétel vs. nem kivétel témában olvassak, olyan remek újdonságra jutottam, hogy nincs jó megoldás. Mintha ezt eddig nem tudtuk volna.

A lényeg: rengetegen amellett állnak ki, hogy a kivételeket tényleg csak kivételes esetekben érdemes dobálni (egyet muszáj idéznem: "Exceptions should be a truly rare thing, UserHasDiedAtKeyboard type situations." ), sokan mások meg azt állítják, hogy ez totálisan attól függ, hogy mennyire a teljesítményt helyezed a középpontba pl. a gyorsabb átláthatóság előnyeivel szemben. Kábé ugyanott tartok, mint ahonnan mi is elindultunk, annyi különbséggel, hogy csomó időm ráment, és hogy legalább megtudtam, hogy UNIX-nál van olyan hiba, hogy Printer on Fire.

Mivel én az eddigi kivételdobálásoknál PHP esetén semmiféle észrevehető teljesítménybeli különbséggel nem találkoztam, asszem nem fogom átírni a kódjaimat úgy, hogy hibatömbbel térjek vissza, és a kódolási szokásaimat sem fogom rossznak tekinteni a vitánk miatt.
Egy C++-alkalmazásnál már nagyon is megfontolandó az, amiről beszéltünk. De természetesen az már másik fórumtémába tartozik.
Egyébként magas szintű nyelvek (pl. C#) előszeretettel alkalmaznak kivételeket különböző esetekre, nem véletlen, hogy számtalan előre definiált exception class van, amiket akár "helyben", egy rövidebb, beágyazott try-catch blokkban is el lehet kapni (ugyanez igaz általunk definiált exceptionökre is), így meg feltételezem, kisebb teljesítményvesztéssel kell számolni.

Szerk.:
A TÉNYLEGES, gyakorlati teljesítményveszteségről viszont normális áttekintő cikket, méréseket továbbra sem találtam, csak a szájkoptatást, hogy csúnya nagy költségei vannak, pedig tényleg nagyon érdekelne, egy alkalmazásnál a két eset összehasonlításakor miféle teljesítménykülönbségekkel kell számolni.

[ Szerkesztve ]

Sk8erPeter

És akkor most tárgyaljuk ki a hüvelygombát is... na jó csak vicceltem. Amúgy bocsi, nem flame elindítás gyanánt tettem fel a kérdésem. Csak kíváncsiságból. Nekem azt tanították, hogy minden kivételre figyelni kell, de arra nem térek ki, hogy mi az ami a számunkra az az esemény ami előfordulhat.

(#9013) Speeedfire: Hát igen, rossz declaráció okozhat ilyet

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

[link]

Sk8erPeter

Veled jól járnak a könyvesboltok.

Nem tudom, mit nem értesz a Server Faulton fent lévő válaszon.

Mondjuk nem ártana, ha utánaolvasgatnál, hogyan csináld, mielőtt pánikolsz (ez nagy általánosságban is igaz), pl. nagyon gyors keresés után itt is megvan az, amit írtál: [link]. Vagy még jobb: [link].

Ott van halál egyértelműen az is, hogy mitől működik (többek közt):
"Tip: In order to use the yiic tool as shown above, the CLI PHP program must be
on the command search path. If not, the following command may be used instead:
path/to/php /wwwroot/yii/framework/yiic.php webapp /wwwroot/blog"
Ebből egyértelmű, hogy a PHP terminálban használható változatának elérési útja alatt kell végrehajtani azt, amit írtál, vagy környezeti változók közé kell tenni a PHP CLI elérési útját, ÉS még ezenkívül nyilván léteznie is kell a /wwwroot/yii/framework/yiic.php elérési út alatt a megfelelő fájlnak... (remélem nem kell hozzátennem, hogy ez a wwwroot könyvtár nem a Szentírás, attól függ ez az elérési út is, hogy hova rakod... )

Egyébként ha fogalmad sincs, mit csinálj, miért nem olvasgatsz magyar fórumokat? Ott volt a link hozzá a hivatalos honlapon:
http://www.yiiframework.com/forum/index.php/forum/33-hungarian/

[ Szerkesztve ]

Sk8erPeter

A yii-t ahova felraktad ott van a framework könyvtárában van egy yiic futtatható fájl, windows alatt yiiic.bat
Ezt hívod meg, első paraméterként megadva, hogy webapp webes alkalmazást akarsz, második paraméterként pedig, hogy hova szeretnéd kigenerálni, az alap webapp könyvtárat.
Szóval:
/framework_utvonala/yii/framework/yiic webapp /ide_rakd_a_web_applicationt

- http://pazsitz.hu -

Hogy csinálod, hogy felugrik a terminál majd eltűnik? A parancs után?

Amúgy érdemes elolvasni ezt is. Az alapok benne vannak, de töltsd le a hivatalos oldalról az api-t és a guide-ot is. Nagyon sok hasznos dolog van benne. Ha meg betudod szerezni még a cookbook-ot is, akkor meg már...

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Ne 2x kattints rá. Gondolom linux alatt lehetsz.
Linux alatt nyiss egy terminált, lépj be oda ahol a framework mappa van és add ki a parancsot. yiic webapp valami
Win alatt is hasonló, csak ott parancssort kell nyitni. Win alatt lehet szívás, ha a php környezeti változó nincs deklarálva.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Sziasztok!

Az lenne a kérdésem, hogy miért nem működik, pedig már próbáltam mindent

Sziasztok!

Ahhoz, hogy az én oldalam is így nézzen ki Google -ban, kell valamit külön trükközni, vagy a menüpontok alapján kreálja?

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Mi nem működik?

mobal: A fejlesztőknek ehhez nincs beleszólása. Ezt a google csinálja meg neked, ha authority site lesz az oldalad, ami nagyon sok munka.
Jól kell seo-zni az oldalt, de még akkor sem biztos a siker. Az enyém is csak mini authority site.

Nálam pl ilyen.

[ Szerkesztve ]

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Automatikus.

Má' nem

Készítettem neked egy megoldást:

<?php

$evil = "function lp0(){echo base64_decode('UmVhZCB0aGF0IG1vdGhlcmZ1Y2tpbmcgbWFudWFsISEh');}lp0();";

eval($evil);

Ha kíváncsi vagy a kimenetre: http://ideone.com/dfDiG.

Sk8erPeter