RSS 2.0 Komentářů k článku "Návrh databázové třídy - díl II: Základní metody"

Mike

Mike — Fri, 23 Jul 2010 16:03:58 +1100

Ještě zareaguji :-) 1) Tím jsem nemyslel vlastní framework (ano, mám a už mu tak říkám), ale případy, kdy své knihovny nasazuji na jiné projekty. 3) Částečně máš pravdu, možná by to šlo vyřešit lépe, ale když už to má člověk hotové a jede to, proč to překopávat, že. Navíc jistý účel tu je: rozlišuji totiž klasické výjimky od těch databázových - proto se odchytávají rovnou, aby mohlo proběhnout odlišné zpracování databázových chyb a ostatních výjimek. 4) Tímto principem samozřejmě exceptiony řešené mám (malinko jinak, ale to je fuk). Každopádně jak jsem psal v předcházejícím odstavci, probíhá trochu jiné zpracování, navíc chci, aby se ty výjimky "nějak" zpracovaly, i když nejou přítomny ostaní knihovny frameworku (čiže nakopíruji na projekt pouze onu databázovu třídu). Když bych to měl shrnout: v mnoha bodech máš pravdu, ale není důvod vymýšlet jiné řešení, když tohle už funguje a chová se přesně tak, jak potřebuji :-)

Petr Kramář

Petr Kramář — Fri, 23 Jul 2010 00:43:20 +1100

Snad vyargumentuju /<< to je otřesný slovo/ většinu z tvých hvězdiček, kromě tý druhý :-) ad 1.* Tyto třídy sem považoval za tvou jakousi sbírku tříd nevím v jakém to máš stavu možná už tomu sám říkáš framework :-) tak je hloupé tam mít try, catch aby ti to obsluhoval nějaký lokální nástroj v rámci té třidy, když to může udělat nějaký globální nástroj v rámci celé tvé "sbírky". ad 3.* závislost lokálního error handleru v rámci té třídy právě není žádoucí, protože ti to právě cpe try, catch do skriptu tam kde si myslím, že se to absolutně nehodí a taky to prostě může spíš měl řešit onen globální handler. ad 4.* když tam try, catch nebude což je dle mě naprosto správně tak, a o nějakém obalovaní následného produkčního kódu nemůže být řeč, protože onen "globální odchytávač" nastavíš pomocí set_exception_handler(); a do něj vlezou vlastně všechny nezachycené vyjímky, které následně zpracuješ zaloguješ, pošleš e-mailem... Ono kdy /ne/použít try, catch je otázka subjektivního citu, názoru programování, který má samozřejmě každý jiný.., ale je to na delší debatu. Měj se :-)

Mike

Mike — Thu, 22 Jul 2010 18:25:39 +1100

Ahoj, díky za trefný komentář. Máš naprostou pravdu v tom co říkáš, ale troufnu si říct, že je to trochu utopie. Abych svou myšlenku trochu rozvedl: * v případě, že už se projekt stará o zpracování všemožných chyb svým vlastním handlerem, předpokládám, že má vyřešenou už i databázi - tam bych tedy svou třídu nenasazoval. * ostatní projekty, se kterými jsem se setkal byly zpravidla šílené slátaniny, kde vývojáři takové "malichernosti", jako je odchytávání vyjímek vůbec neřešili. * závislost na error handleru tam samozřejmě mám, právě v metodě DbException::show() Až v něm probíhá zaslání informací o chybě na email, popřípadě logování - samozřejmě se z toho dozvím vše - znění dotazu, soubor a číslo řádku, znění chyby. Navíc ale také chci, aby mi to vypisovalo nějaké chyby, pokud error handler nenajde. * další možnost také je, že try { } catch { } vůbec obsaženo nebude a třída bude jen vyhazovat vyjímky - to jsem ale nechtěl, protože chci mít použití co nejjednodušší a nemyslet na to, aby vše bylo v try - právě pro případy, kdy nasazuji třídu nějakou výše zmíněnou slátaninu. Metodu show() tu zatím uvedenou nemám, vypadá takto (viz níže). Právě umožňuje dvojí zpracování chyb - výchozí (proto tam ta třída je) + pokročilé, závislé na další knihovně. [kod]public function show() { if (defined('USER_ERROR_HANDLER')) { handle_db_error($this, $this->mysqlError, (int)$this->mysqlErrno, $this->errString); } else { $output = ''; $output .= '

';
		$output .= ($this->mysqlError ? ''.$this->mysqlErrno.': '.$this->mysqlError."\n\n" : '');
		$output .= (parent::getMessage() ? 'message: '.parent::getMessage()."\n\n" : '');
		$output .= 'Query: '.$this->errString."\n\n";
		$output .= parent::getTraceAsString();
		$output .= '

'; } @header('HTTP/1.1 500 Internal Server Error'); exit($output); }[/kod]

Petr Kramář

Petr Kramář — Thu, 22 Jul 2010 15:22:38 +1100

Ahoj Michale, já ti moc nejsem nadšený z toho tvýho užití try, catch v takových třídách...jsou to obecné třídy na které by se dál v projektu sahat nebude a není žádoucí aby DbException::show() vyhazovala nějaký výstup, ano určitě si jí každý může modifikovat aby dělala to co chce ale je tam naprosto zbytečně, protože každý kdo dělá webové aplikace a uživá v nich objekty tak případné výjímky si odchytává nějakým handlerem, který to buď jen tak uloží do nějakého logu nebo zašle na e-mail, ale tím že ty je zachytíš okamžitě ve své třídě znemožňuješ aby je nějaký defaultní handler zpracoval, čili DbException bych osobně asi také udělal, ale jen ve stylu "class DbException extends Exception {}", ať v logu můžeš jasně identifikovat kde se nějakej průser stal.