- Android alkalmazások - szoftver kibeszélő topik
- Mobil flották
- Redmi Note 13 Pro+ - a fejlődés íve
- Milyen okostelefont vegyek?
- Fotók, videók mobillal
- Samsung Galaxy S23 FE - nincsen sárkány
- Okosóra és okoskiegészítő topik
- Samsung Galaxy S23 Ultra - non plus ultra
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Huawei Pura 70 - fura lettem
Új hozzászólás Aktív témák
-
#8951
Speeedfire
félisten
PazsitZ
#8950
Speeedfire
félisten
válasz
PazsitZ
#8950
üzenetére
Igen, pont én is ezt próbáltam, de már nem akartam írni, hogy megadom neki, hogy isNewRecord, de akkor még a primary key marad.
Így végül maradt a new Model.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
#8954
Sk8erPeter
nagyúr
Speeedfire
#8943
Sk8erPeter
nagyúr
válasz
Speeedfire
#8943
üzenetére
Ezt már korábban írtam, de ennek ebben a formában nem sok teteje van:
isset($_POST['hirlevel']) ? $hirlevel = 'igen' : $hirlevel = 'nem';Így tulajdonképpen nem indokolt, hogy miért ne használd inkább az if-else formát.
Akkor már itt is leírom úgy, ahogy még értelme is van ezt a formát használni:
$hirlevel = isset($_POST['hirlevel']) ? 'igen' : 'nem';
Így még teljesíti is azt a célt, hogy érdemben lerövidíti a kódot, és nem kell ugyanazt a változónevet ismételgetni (ahogy pl. egy if-else feltételvizsgálatnál). Meg utóbbi formában gyorsan átlátható, milyen értéket szeretnél egyből hozzárendelni, és milyen feltételtől teszed azt függővé.[ Szerkesztve ]
Sk8erPeter
-
#8955
modder
aktív tag
Sk8erPeter
#8954
modder
aktív tag
válasz
Sk8erPeter
#8954
üzenetére
nem beszélve arról, hogy emlékeim szerint le sem fordul így
isset($_POST['hirlevel']) ? $hirlevel = 'igen' : $hirlevel = 'nem';(talán lehet vele trükközni, hogy kapcsos zárójelbe teszed, de lehet, hogy akkor is kell az egyes ágaknak visszatérési érték)
-
#8957
Speeedfire
félisten
Sk8erPeter
#8954
Speeedfire
félisten
válasz
Sk8erPeter
#8954
üzenetére
Igyekszem megjegyezni.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
#8958
modder
aktív tag
Sk8erPeter
#8956
modder
aktív tag
válasz
Sk8erPeter
#8956
üzenetére
ez esetben csak vicceltem!
![;]](//cdn.rios.hu/dl/s/v1.gif)
amúgy én lehet, hogy "picsahülye vagyok az egészhez", de valamelyik programnyelvben akkor is hibát dobott a példakódra
(C vagy Java talán vagy mind2) -
#8959
Peter Kiss
őstag
Peter Kiss
őstag
-
#8961
modder
aktív tag
Peter Kiss
#8959
modder
aktív tag
válasz
Peter Kiss
#8959
üzenetére
jajj
el lehet játszani ilyenekkel, de ugyanehhez a funkcionalitáshoz elég csak egy __call() fv-t használni -
#8963
Peter Kiss
őstag
Sk8erPeter
#8954
Peter Kiss
őstag
válasz
Sk8erPeter
#8954
üzenetére
Az első forma karcolja a hülyeség fogalmát, és valóban nem fordul le minden nyelven.
PHP 5.3 óta egyébként van egyszerűsített is:
$tmp = $someVariable ?: "Hello world";Ha $someVariable létezik, és true-t ad a kiértékelés folyamán, akkor az ő értékét veszi fel a $tmp, egyébként "Hello world" lesz. Ha a $someVariable nem létezik, error.
---
#8961: __call-lal nincs kódkiegészítés, és nyilván szar ötlet eval()-lal használni, de lehetséges. Bár látszólag csak overhead-et pakol a kódba, ha ilyet használ valaki.
[ Szerkesztve ]
-
#8964
Sk8erPeter
nagyúr
Peter Kiss
#8963
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8963
üzenetére
Jaja, vágesz, szerencsére szép lassan fejlődget a PHP. Most moddert UTÁNOZVA (
) feliratkoztam én is a PHP Internals levlistára, ott éppen arról tárgyalnak, hogy a C#-os getter-setterhez hasonló metódusokat a __get() helyett vagy mellett be lehetne tenni a core-ba.Egyetértek, totál semmi értelme annak a kódnak, amit írt. Igazából ezt most ezzel együtt már harmadjára írom le.
De megmondom őszintén, annak az eval()-os példának sincs túl sok, amit imént írtál.
Beraktad egy stringbe, kiértékelted, és?[ Szerkesztve ]
Sk8erPeter
-
#8965
cAby
tag
Sk8erPeter
#8938
cAby
tag
válasz
Sk8erPeter
#8938
üzenetére
Köszi, akkor körülnézek majd AJAX témában.
-
Helló!
Segítsetek! Hogyan tudnám megoldani legegyszerűbben a lapozás témát?
Pl.:
http://my-website.com/archive/2012/03/page/1
Erre gondolok. Milyen jó megoldás létezik rá? És esetleg olyan amit több függvényre is rá lehet húzni?
Pl.:
http://my-website.com/archive/2012/03/page/1
http://my-website.com/articles/2012/03/page/1Két külön metódus, egy kontrollerbe - archive és articles - de maga a "page" generálo dolog ugyan az.
Köszi!
mobal
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
modder
aktív tag
A paginálás nem egyszerű dolog. Gyakorlatilag kell egy olyan osztály, ami képes egy k : [1,n] (ahol k az oldal száma) egész számot leképezni az adatbázis által visszaadott rekordok intervallumaira.
page 1 -> mysql sorok(0,10)
page 2 -> mysql sorok(11, 20)
...Itt a mysql lekérdezésben a LIMIT és az OFFSET-tel szoktak operálni (MySQL-ben), vagy ha az adatbázis interfészed tud ilyen funkcionalitást megvalósító fv-eket, akkor azzal.
kb ez úgy néz ki, hogy ha tudod, hogy 1 oldalon 30 elemet akarsz megjeleníteni, akkor osztályod úgy készíti el az adatbázis lekérdezést az elemeidre, amiket meg akarsz jeleníteni, hogy:
$sql .= ' ORDER BY ido DESC LIMIT 30 OFFSET ' . $page * 30 . ';';
van nagyon sok működő megoldás neten, csak keresgélj.
[ Szerkesztve ]
-
#8969
Sk8erPeter
nagyúr
modder
#8967
Sk8erPeter
nagyúr
Érdekesség, hogy ez a szintaxis a PostgreSQL-lel való kompatibilitás miatt került bele:
SELECT Syntax - LIMIT clause
"For compatibility with PostgreSQL, MySQL also supports the LIMIT row_count OFFSET offset syntax."Egyébként:
"LIMIT takes one or two numeric arguments, which must both be nonnegative integer constants (except when using prepared statements).
With two arguments, the first argument specifies the offset of the first row to return, and the second specifies the maximum number of rows to return. The offset of the initial row is 0 (not 1):
SELECT * FROM tbl LIMIT 5,10; # Retrieve rows 6-15
To retrieve all rows from a certain offset up to the end of the result set, you can use some large number for the second parameter. This statement retrieves all rows from the 96th row to the last:SELECT * FROM tbl LIMIT 95,18446744073709551615;
With one argument, the value specifies the number of rows to return from the beginning of the result set:SELECT * FROM tbl LIMIT 5; # Retrieve first 5 rows
In other words, LIMIT row_count is equivalent to LIMIT 0, row_count."A phpMyAdmin is utóbbi szintaxist használja.
Persze teljesen jó az említett OFFSET-et tartalmazó szintaxis, meg talán kifejezőbb is a query általa, de említésre méltó az idézett változat is, hátha valaki azt ismeri jobban - MySQL query-knél én utóbbit gyakrabban szoktam látni kész kódokban (nyilván a másikra is bőven akad példa).[ Szerkesztve ]
Sk8erPeter
-
#8970
modder
aktív tag
Sk8erPeter
#8969
modder
aktív tag
válasz
Sk8erPeter
#8969
üzenetére
Ó, ezt nem tudtam. Köszönöm a kiegészítést!
-
raczger
őstag
Remélem ide még elfér egy htaccess probléma. A gondom az, hogy az alábbi url rwerite apache 2.0-nál tökéletesen működik, 2.2-nél viszont nem:
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php [QSA]
Mindössze az a célom, hogy bármely nem létező url-nél az index.php-t hozza be. Valamiért a 2.2-nél, ha pl a /tagok/lista url-t szeretném behozni, ez automatikusan a /tagok/lista.php-t tölti be (miért adja hozzá automatikusan a kiterjesztést???), de ha a /tagok/lista.php-t szeretném direktbe behívni, akkor nem érzékeli mint létező fájlt, ezért az index.php-t tölti be.www.movat.hu - http://bit.ly/2mIziA4
-
#8973
Sk8erPeter
nagyúr
raczger
#8972
Sk8erPeter
nagyúr
válasz
raczger
#8972
üzenetére
Ha nem szeretnéd, hogy a kiterjesztés hozzá legyen adva Apache esetén, szedd ki explicite a MultiViews opciót, ajánlott rövid cikk a témában, ami pont URL-átírásos problémáról szól: [link]. Az ott linkelt másik doksi még rövidebben összefoglalja: [link].
[ Szerkesztve ]
Sk8erPeter
-
#8974
raczger
őstag
Sk8erPeter
#8973
raczger
őstag
válasz
Sk8erPeter
#8973
üzenetére
köszönöm, de ez nálam nem működik... lehetséges, hogy a szolgáltató ezt tudja korlátozni, az ilyen beállításokat?
www.movat.hu - http://bit.ly/2mIziA4
-
#8975
Sk8erPeter
nagyúr
raczger
#8974
Sk8erPeter
nagyúr
válasz
raczger
#8974
üzenetére
.htaccess fájlba tetted? Mondjuk gondolom igen. Elég furcsa, hogy nem működik. Végül is lehet, hogy az Options direktíva buzerálását le tudja tiltani a szolgáltató, mondjuk eléggé hülyeség lenne a részükről.
[link]
Pedig ez olyan opció, ami állítható.De inkább közelítsük meg másfelől a kérdést: akkor a rewrite rule-lal lehetne valamit babrálni.
Vegyük példának a Drupalt, ott is minden egyes kérés, ami nem fájlrendszerben létező fájlra vagy könyvtárra vonatkozik, ráfut az index.php-re:# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
### ...........
# Pass all requests not referring directly to files in the filesystem to
# index.php. Clean URLs are handled in drupal_environment_initialize().
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]
</IfModule>A drupal_environment_initialize() függvény kezeli a továbbiakat.
A korábbi, 6-os verziónál még így nézett ki:
# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>Tehát itt explicite a q paraméternek adódott át a kérés, ezt a Drupal pedig lekezelte magának.
Sk8erPeter
-
#8976
raczger
őstag
Sk8erPeter
#8975
raczger
őstag
válasz
Sk8erPeter
#8975
üzenetére
sikerült megoldanom és végül nem ezzel volt a probléma... egy-két fájlt nem töltött fel/le rendesen, ebből adódott a probléma, korábban volt hasonló problémám, azt hittem ugyanez lesz a baja de nem, köszi a segítséget
www.movat.hu - http://bit.ly/2mIziA4
-
spammer
veterán
Na szakik, lenne egy kérdésem, bár nem tudom, kivitelezhető-e, amit akarok
- Van egy megrendelőlap (php) form, textfield, textarea stb. ami emailben küldi el az adatokat.
- Aztán van egy terméklista oldal, képekkel, cikkszámmal stb, szintén php.Meg lehet-e oldani azt, hogy a terméklistás oldalon mondjuk egy termék kódjára/cikkszámára kattintva azt a kódot beírja a megrendelőlap megfelelő "rovatába" (textarea).
Nincs adatbázis, szóval valamilyen cookie-s megoldásra gondoltam, így több terméket is rá lehetne küldeni a megrendelőlapra, és nyilván kellene egy "törlés" opció is, ha netán mégis más termék kellene, akkor ne ragadjon be cookie miatt.
Megoldható ilyen módszerrel?
„A feketébe öltözött ember a sivatagon át menekült, a harcos pedig követte."
-
modder
aktív tag
válasz
spammer
#8977
üzenetére
szerintem is, kukis az biztos működni fog, és viszonylag egyszerű is, ha csak cikkszámok listájáról van szó. esetleg megnézhetsz valami LocalStorage dolgot (keress rá). ez asszem ilyen HTML5-ös szabvány.
Ha nincs DB, még a cikkszámra kattintva akár egy AJAX-os megoldással (hogy ne töltődjön újra az oldal) session változóba is mentheted a cikkszámokat.
-
Sziasztok!
Az úgy jó megoldás, ha nem talál az oldal mondjuk egy bejegyzést, akkor dob egy 404 es kivételt, amit a framework lekezel, és megjeleníti a hozzá tartozó hibakóddal az hiba oldalát?
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
#8983
Speeedfire
félisten
mobal
#8981
Speeedfire
félisten
Korrekt! A jobb framework-ök, cms-ek is ezt csinálják. De ami a legjobban bejött és nem láttam még kész megoldást rá.
pl valaki erre linkel, hogy http://valami.hu/kis-suti-eves-volt-pesten
erre dobja, hogy 404, de olyat talál az adatbázisban, hogy:
http://valami.hui/nagy-suti-eves-volt-pesten vagy http://valami.hui/kis-suti-eves-volt-gyorben és felajánlja neked, hogy nem ezt akartad?
Jóféle dolog, de gondolom valami alapján felbontja a requert url-t és úgy keresgél az adatbázisban vagy valami ilyesmi.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
#8984
Sk8erPeter
nagyúr
Speeedfire
#8983
Sk8erPeter
nagyúr
válasz
Speeedfire
#8983
üzenetére
Az ötlet jó, egy ilyen jellegű megoldás pl. ehhez hasonló lehet: [link]
Ez a cikk írójának saját megoldásával korábbi Drupal-verzióhoz azt csinálta, hogy a request URI-t felbontotta, és eszerint futtatott le egy keresést. Ezt a keresést mondjuk be kellene helyettesíteni egy alias-kereséssel, ráadásul itt nem gondol az ékezetes karaktereket tartalmazó URL-ekre, amiből manapság már bőven van (lásd pl. drupal.hu).
Persze ez most a felvetésedre nem megoldás, szóval nem egy kész, hűdefasza kód, de legalább valaki próbált nyekeregni egy kicsit erőltetetten a témában, azért linkeltem.
Igazából én is csak most kerestem rá, eddig nem jutott eszembe alias szerint keresgélni és javaslatokat mutatni, de tényleg jó ötlet lehet, főleg, hogy az aliasok jobb helyeken adatbázisban, külön erre szentelt táblában találhatók, így normális indexeléssel egy ilyen táblában való kutakodás elég gyors lehet.Sk8erPeter
-
#8985
mobal
MODERÁTOR
Sk8erPeter
#8982
válasz
Sk8erPeter
#8982
üzenetére
Jó csak amennyire tudom szeretném elkerülni a kivételeket. De akkor ezekszerintjólgondoltam!
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
modder
aktív tag
szerintem ez, hogy kivételt dobsz, vagy hogy kezeled le azt, ha nem talál a keretrendszered egy oldalt, az rajtad múlik. Általában ugye úgy működik egy mvc architektúrájú keretrendszer, hogy megkeresi az url vagy route alapján ráillő kontrollert.
Lehet az, hogy nincs meg a kontroller vagy nincs meg a kontroller által kiszolgálandó erőforrás, például cikk, termék.
Ha nem találja a kontrollert vagy az adott oldalt, cikket, akármit, amit beírt a felhasználó az url-be, akkor akár helyben is -- ott ahol kiderült, hogy nincsen sehol a kérdéses erőforrás -- küldhetsz az outputra egy 404-et, majd "szép leállást" produkálsz pl. zárod a logokat. Erre csinálhatsz egy függvényt vagy beleraod a response osztályodba, és hívsz egy iylet, hogy $this->response->out_404();
Így meg mindegy, hogy exception-t dobsz-e vagy helyben egy függvényen belül kezeled-e le a dolgokat, mert hiba esetén meghívni egy exception-t vagy egy függvényt ugyanannyi kódolás minden esetben, bár utóbbinál legalább nem operálsz exceptionökkel.
-
Most úgy van, hogy első körben ellenőrzöm a kérelmet, tehát, hogy a controller és az akció megvan -e. Utána pedig magát a tartalmat, pl.: egy bejegyzés megtalálható e. Ebben a két külön esetben dobok egy 404 -et ha nincs.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
#8992
Speeedfire
félisten
Sk8erPeter
#8984
Speeedfire
félisten
válasz
Sk8erPeter
#8984
üzenetére
Nem rossz megoldás, egyszer ha lesz hozzá kedvem lehet, hogy nekiesek és megpróbálom megoldani, mert jópofa és a usernek is segít.
mobal: F12?
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
#8994
Sk8erPeter
nagyúr
mobal
#8985
Sk8erPeter
nagyúr
"csak amennyire tudom szeretném elkerülni a kivételeket"
Szerintem ez egyáltalán nem indokolt. Még ha a futási időhöz hozzá is teszel párszázadmásodpercnyit, a kivételkezelés akkor is ezerszer átláthatóbb hibakezelési forma, mint pl. a hatezer soros if-else blokkok. A kivételkezelésnél ezenkívül a saját kivételosztályaidat is felhasználhatod, az Exception osztály felülbírálásával, amibe tetszőleges kódot pakolhatsz, többek közt pl. naplózást, ami igen fontos lehet, és esetfüggő lehet, mit, hogyan és hova szeretnél naplózni. Viszont egy form esetén pl. nyilván nem naplózol, ha egy mezőt nem töltöttek ki. Ha az if-else blokkos megoldást választod, akkor viszont naplózási igény esetén azt valahogy bele kell tákolnod a blokkjaidba, nem marad egy szeparált helyen, ahogy pl. a kivételosztályaidat kigyűjtheted egy teljesen különálló fájlba. Nem beszélve arról, hogy a kivétel forrása (melyik sorban, melyik fájlban dobódott, stb.) nagyon könnyen felderíthető a kivétel elkapásakor, teljesen mindegy, hol, melyik függvényen belül dobtad el, azt a try-catch blokkban elkapod, majd lenyomozod, mi is volt a baj.
Egy szó, mint száz: a kivételkezelés szerintem épp, hogy nem egy kerülendő dolog, hanem érdemes alkalmazni.Egyébként pl. a PDO-nál is lehet "hagyományos úton" is hibákat kezelni, meg lehet úgy is inicializálni, hogy megmondod neki, hogy kivételeket dobjon, ne visszatérési értékeket kelljen vizsgálgatni, ami csak feleslegesen csinál a kódodból spagettikódot. Nem tudom, hogy vagytok vele, de én maradok a kivételkezelésnél.
Sk8erPeter
-
#8995
modder
aktív tag
Sk8erPeter
#8994
modder
aktív tag
válasz
Sk8erPeter
#8994
üzenetére
Én csak ezzel nem értek egyet:
a kivételkezelés akkor is ezerszer átláthatóbb hibakezelési formaKivételkezelést akkor érdemes használni, amikor egy mély hívássorozat alján keletkezik valahol egy kivételes hiba, és ezt sokkal fentebbi függvényben akarod lekezelni. Ilyen például az adatbázis absztrakciós rétegekben egy mysql hiba, ami, ha jó a kódod, ritkán fordul elő, és általában elég csak annyira foglalkozni vele, hogy loggolod.
Vissza a fenti mondathoz. Ha a kivételkezelést általános programozási gyakorlattá teszed, annak megvan az a hátránya, hogy később, ha ránézel a kódra, nem biztos, hogy fogod tudni, hogy a kivételedet hol dobod (ahogy említetted, amíg ténylegesen nem történt ilyen exception, akkor stacktrace), és amikor refaktorálod a kódot, fogni fogod a fejed.
Még egy dolog.
Ha az osztályodat majd újra fel akarod használni, nem szabad megfeledkezni arról, hogy milyen kivételeket dobhat. Amíg jól van dokumentálva a kódod, addig nem biztos, hogy fejtörést fog okozni, de ha már kevesebb időt töltesz a dokumentálással, valahol újra fel akarod használni a kódodat, szintén fogni fogod a fejed, mert fejlesztés során olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak, ahogy az osztályod egyre többet tud.Ezt a Dependency Injectionhöz tudom hasonlítani. Ott arról van szó, hogy bizonyos műveleteknek vannak előfeltételei, előfeltétel objektumai, és addig átlátható, amíg a függvények bemenetein megjelennek ezek az előfeltételek, mert addig nyomonkövethető a kdóban az előfeltétel.
Egy szó, mint száz. Nem érdemes általános gyakorlattá tenni a kivételek dobálását. Form validálásnál még talán elmegy. De ezt is lehet hit kérdéssé tenni, nem muszáj rám hallgatni
-
PazsitZ
addikt
Nem értem ezt az exception költséges dolgot.
Az oop is költséges, főképp korábbi php verziókban.
De valamit valamiért.
Az meg hogy ilyenekkel nyersz 1 századmásodpercet, nem hiszem, hogy mérvadó.(#8995) modder:
Nem értem mi a problémád az exceptionnel?
Avagy mivel váltod ki, ami szerinted jobb/átláthatóbb?nem biztos, hogy fogod tudni, hogy a kivételedet hol dobod
A kivételed jobb esetben megmondja mi a hiba, így illene tudnod, hol dobod. A modul vagy egyéb logikai egységhez dedikált kiterjesztett kivételosztályról nem is beszélve, ami teljesen egyértelművé teszi, miért és hol használod. Legrosszabb esetben egyébként pedig egy stacktrace meg nehogy már ördögtől való körülményes találmány legyen.
Az hogy dokumentálsz alap, plusz egy exception annotációba - amit jobb esetben az IDE kapásból kigenerál neked- nem kellene belehalni.A kivételek öröklődése és funkcionális kiterjeszthetősége (pl. logolás), amit említettek is, meg csak hab a tortán a használata mellett.
[ Szerkesztve ]
- http://pazsitz.hu -
-
#8997
Sk8erPeter
nagyúr
modder
#8995
Sk8erPeter
nagyúr
"Kivételkezelést akkor érdemes használni, amikor egy mély hívássorozat alján keletkezik valahol egy kivételes hiba, és ezt sokkal fentebbi függvényben akarod lekezelni. Ilyen például az adatbázis absztrakciós rétegekben egy mysql hiba, ami, ha jó a kódod, ritkán fordul elő, és általában elég csak annyira foglalkozni vele, hogy loggolod."
1.) Nem értem, ez miért változtat azon az állításomon, hogy átláthatóság szempontjából mindenképp jobb. Azt hittem, a privátban kitárgyalt kód meggyőző volt ennek alátámasztására.
2.) A MySQL-hiba jobb esetben - pl. elég ritka, hogy az adatbázishoz tartozó service lehal - valóban ritkán fordul elő. De azért ne csináljunk úgy, mintha csak ennyire szélsőséges esetekre lehetne alkalmazni a kivételeket."Ha a kivételkezelést általános programozási gyakorlattá teszed, annak megvan az a hátránya, hogy később, ha ránézel a kódra, nem biztos, hogy fogod tudni, hogy a kivételedet hol dobod (ahogy említetted, amíg ténylegesen nem történt ilyen exception, akkor stacktrace), és amikor refaktorálod a kódot, fogni fogod a fejed."
Ezt pontosan azért nem értem, mert az előző hozzászólásomban éppen azt hoztam fel a kivételek egyik előnyeként, hogy a lehető legegyszerűbb kideríteni, honnan származik a kivétel, és naplózás esetén nálam legalábbis alap, hogy a kivételek forrását is naplózom: melyik fájlban keletkezett a kivétel, melyik függvényben, a fájlnak pontosan melyik sorában, mikor, stb. Ezeket az exceptionökből a lehető legegyszerűbb feladatok egyike kideríteni, így pontosan ezért nem értem, miért is lenne érv jelen esetben az, hogy "nem biztos, hogy fogod tudni, a kivételedet hol dobod" - dehogynem, pontosan fogom tudni: lásd pl. getFile(), getLine(), getTrace() vagy épp getTraceAsString() függvények...Régen, mielőtt a kivételkezelést egyáltalán alkalmaztam volna, pontosan az volt a bajom, hogy sok esetben nehezen visszakövethető, hogy konkrétan hol is történt a hiba, és milyen jellegű is volt. Most meg pl. ránézek a naplóra, és egész pontosan meg tudom nézni, hol és mi is történt, valamint a kivétel mikor keletkezett.
"Ha az osztályodat majd újra fel akarod használni, nem szabad megfeledkezni arról, hogy milyen kivételeket dobhat. Amíg jól van dokumentálva a kódod, addig nem biztos, hogy fejtörést fog okozni, de ha már kevesebb időt töltesz a dokumentálással, valahol újra fel akarod használni a kódodat, szintén fogni fogod a fejed, mert fejlesztés során olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak, ahogy az osztályod egyre többet tud."
Kezdjük azzal, hogy szerintem a rossz dokumentáció egyik esetben sem segít a későbbi fejlesztésekben, ebből a szempontból teljesen lényegtelen, hogy most kivételeket dobálsz, vagy az adott esetben túlságosan is kövérre hízó, macerás if-else blokkokat alkalmazod.
Ha pedig említetted az error tömbök visszaadását: ha épp a szar dokumentáció és az újrafelhasználás a példa, akkor hogyan emlékezz vissza, hogy mi is volt a megfelelő hibakezelési mód? Pl. hogy az error tömböd milyen formában érkezik, vegyünk egy példát:
$functionReturnValue = $myClass->myMethod();
if( $functionReturnValue['status'] == FALSE ){
......
}
else {
....
}Aztán kiderül, hogy basszus, nem is $functionReturnValue['status'] a megfelelő vizsgálandó visszatérési érték indexe, hanem mondjuk $functionReturnValue['result'].
Ha viszont eldobsz egy kivételt a hiba forrásánál, az garantált, hogy itt minél előbb megtudod, hol keletkezett a hiba (pl. ha fent van egy Xdebug extension, akkor az még szép táblázatos formában ki is írja neked), és nem próbálod folytatni a programkódot a rossz visszatérési értékekkel, stb.De hogy még reagáljak arra is érdemben, hogy "olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak":
erre röviden az az egyszerű reakció, hogy ha az egész try-catch blokkod legvégére a kivételosztályok ősosztályának elkapását is elintézed, akkor nyilván nem mondok újat azzal, hogy így minden kivételt elkapsz, azt is, ami specifikusan nem volt lekezelve.
Ezeket pedig szintén naplózhatod, és akkor tudod, hogy még milyen kivétel nincs lekezelve.
Pl.:
try {
$stuff = new MyClass();
// exceptiont fogsz eldobni, mégpedig így:
// throw new MyNewException( 'asdasd' );
$stuff->myMethod();
} catch ( MyOldException $e ){
...
} catch ( AnyOtherException $e ){
...
} catch ( Exception $e ){
...
// itt elkapod a többit!!!
}Így tehát azt az esetet is lekezelted, amit előre nem láttál - a másik esetben sokkal nehezebb ennyire általános receptet adni az "egyéb" kategóriába eső hibák megfelelő kezelésére és naplózására.
Sk8erPeter
-
modder
aktív tag
válasz
PazsitZ
#8996
üzenetére
PHP-ban valszeg nem olyan költséges, mint pl. c++-ban.
Ne értsetek félre, jó dolog az exception olyan hibák kezelésében, amik tényleg az elvárt futástól különböző esetekre vannak.
Ezen kívül azonban, amikor a program funkcionalitásába belekalkulált dolgokról van szó, mint például: S8erPeter-nek volt egy form validálós, feldolgozós példája, ahol hiba esetén kivételt dob, illetve a fentebb tárgyalt esetben, hogy nem talál egy oldalt, akkor exception-t dobjon, amikor az egy belekalkulált működés, szerintem; az exception számomra egy kerülő megoldás, ahol ide-oda ugrálunk a kódban.
Itt tulajdonképpen arról van szó, hogy milyen 'hiba' vagy kivételes eset fordulhat elő többször, amire számítani kell, és mi a valódi hiba (ez utóbbi esetben érdemes kivételt használni). Nem láttam még olyan keretrendszert, ami kivételdobásokra alapozta volna a működését.Nekem ez az álláspontom. Nem éles a határ, hogy mikor érdemes kivételeket használni, nem egyértelmű eldönteni, de én ott például, ahol user input validálást csinálok, számítok rá, hogy rossz lesz az input, és nem fogok kivételeket dobálni rossz inputra.
Egyébként meg mindenki úgy programoz, ahogy akar.
...A dokumentálás meg egyáltalán nem alap, gyors fejlesztési ütemben pedig mindig elmarad, de aki megtanul tiszta kódot írni, az a többi fejlesztő munkáját megkönnyíti.
-
#8999
modder
aktív tag
Sk8erPeter
#8997
modder
aktív tag
válasz
Sk8erPeter
#8997
üzenetére
Most már nem fogok mindenre reagálni, leírtam az érveimet. Felőlem mindenki olyan esetekben dobál exception-t a kódjában, ahol akar.
Csak egy pár dolog:
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án kiderül, hogy basszus, nem is $functionReturnValue['status'] a megfelelő vizsgálandó visszatérési érték indexe, hanem mondjuk $functionReturnValue['result'].
Nyilván, ha valaki idiótán programoz, arra nincsen mentség.Aki pedig azt állatja, hogy minden függvényt azzal kezd, hogy /** */, az biztos ráér programozni
-
#9000
Sk8erPeter
nagyúr
modder
#8998
Sk8erPeter
nagyúr
"nem talál egy oldalt, akkor exception-t dobjon, amikor az egy belekalkulált működés, szerintem; az exception számomra egy kerülő megoldás, ahol ide-oda ugrálunk a kódban.
Itt tulajdonképpen arról van szó, hogy milyen 'hiba' vagy kivételes eset fordulhat elő többször, amire számítani kell, és mi a valódi hiba (ez utóbbi esetben érdemes kivételt használni). Nem láttam még olyan keretrendszert, ami kivételdobásokra alapozta volna a működését."Akkor az általad használt Kohana egy szar, mert pl. minden egyes HTTP status code-ra létezik benne exception?
Vegyük az említett példának megfelelőt: HTTP_Exception_404.
Aztán itt bal oldalt láthatod szépen a többit is, ami pl. validálás kapcsán említésre méltó, az a Validation_Exception.
Aztán ott a Kohana_Exception, a Kohana_Request_Exception és a Kohana_View_Exception.Azt hiszem, abban egyetérthetünk, hogy valószínűleg a Kohana alapvetően nem átgondolatlan struktúrára épül.
Hadd említsek egy másik példát: remélem abban is egyetértünk, hogy a Symfony nem egy tákolmány keretrendszer, és valószínűleg nem érdemtelenül népszerű.
Egy - számomra legalábbis - elég meggyőző érv még a témában:
[link]
"Symfony really relies on PHP exceptions for error reporting, which is much better than the way PHP 4 applications work. For instance, the 404 error can be triggered by an sfError404Exception."Akkor most már láthattál egy keretrendszert, ami kivételdobásokra alapozta a működését.
Sk8erPeter
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- MSI GTX 1660 GAMING X 6gb újszerű
- Panasonic CF-20 ütésálló, ipari notebook & tablet számlával, garanciával
- Arctic P12, P14, Slim, Max, PWM, PST
- Lenovo ThinkPad E495 Ryzen 5 pro 3500U, 8GB RAM, 256GB SSD, jó akku, szép állapot, számla, garancia
- Lenovo ThinkPad X395 Ryzen 5 pro 3500U, 16GB RAM, 256GB SSD, jó akku, szép állapot, számla, garancia
Állásajánlatok
Cég: HC Pointer Kft.
Város: Pécs
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest