PHP triky: standardní výjimky

‚Tyto výjimky nemají žádnou funkčnost navíc‘ – mají: zabírají na onom hnojišti jmeného prostoru místo. Ještě štěstí, že je dále nelze modifikovat

Mohl bych položit možná trochu amatérský dotaz (pokud jsem si toho nevšiml v textu článku, omluvte mne, je teprve 8:40).
Existují knihovní funkce PHP (pro práci s poli, s řetězci, s deskriptory atd.), které by zmíněné nebo klidně i zatajené výjimky vyhazovaly? Nechci být nevěřící Tomáš…

musím s tebou dgx souhlasit že hiearchie výjimek v Zend Frameworku je opravdu nešťastná…snad na to jednou pánové přijdou ale to už může být pozdě na to to předělat

#2 jonsone, funkce (tj. nikoliv metody tříd) samozřejmě výjimky nevyhazují. Jednak nemá logiku, aby nonOOP část jazyka vyhazovala objektové výjimky (a žádné neobjektové tam nejsou). Ale především, není možné provést tak zásadní zásah do kompatibility, jakým by bylo vyhazování výjimek u existujících knihovních funkcí. Tím by přestal fungovat jakýkoliv kód. Docela žasnu, jak někdo může po takové úpravě volat.

Naopak metody tříd, které se objevili v PHP 5 (tj. knihovna SPL) některé z těchto výjimek vyhazují. Například ArrayIterator vyhazuje OutOfBoundsException a RuntimeException.

#3 Jakube Podhorský, Problém by to být nemusel, stačí vytvořit potomka současné výjimky pro konkrétní případ, což by mělo být bez problémů zpětně kompatibilní.

Je škoda, že tohle už dávno není v Zendu řešeno. Taky mi to vadí. Pak jsou v dokumentaci uváděny příklady typu

…

} catch (Zend_Pdf_Exception $e) {
    if ($e->getMessage() == 'Can not open \'' . $argv#1 ivan_d . '\' file for reading.') {

…

#3 Jakube Podhorský, Přesně tuhle výtku proti výjimkám v Zend Frameworku jsem už nedávno nadhodil v českém ZF fóru. Kupodivu jsem zjistil, že mezi tamním osazenstvem jsem byl se svým názorem spíš osamocený.

#5 Ronnie, Ano, přes zpětně kompatibilní potomky to řešit lze, jenom se u některých výjimek (například typicky u Zend_Pdf_Exception) musí každému potomkovi natvrdo nastavit i jeho příslušný interní číselný status code.

O těchle výjimkách jsem nevěděl. Díky za dobrý podnět, píšu si to do todo fw :)

#4 Davide Grudle, Díky za odpověď, je fakt, že dotaz jsem položil nejapně ohledně knihovních funkcí, které objektové nejsou.

Nicméně rád bych si nechal poradit: kdybych stál např. o práci se soubory a adresáři objektově a s výjimkami (soubor nelze otevrit pro zapis, neexistuje cesta, neni dost mista na disku …), měl bych použít třeba Pear nebo SPL?
Zkrátka chtěl bych používat něco, kde bude kupříkladu otevřený soubor reprezentován instancí nějaké třídy, ta dává k dispozici metody pro čtení nebo zápis apod. a v případě neúspěchu akce bych nemusel testovat návratové hodnoty, ale mohl zachytávat výjimky. Ideálně aby takové knihovny byly součástí distribuce interpreteru nebo jeho snadno doinstalovatelným rozšířením.

Zkusil jsem ArrayObject z SPL, chtěl jsem výjimku o neexistujícím klíči slovníku, ale nepřišel jsem na to:

$x = new ArrayObject();
$x[‚ahoj‘] = 124;
var_dump($x[‚ahoj‘]);
try {
var_dump($x[‚vyskoc‘]);
} catch (Exception $e) {
echo(‚Heureka!‘);
}

#8 jonsone, Objektový přístup k souborům řeší SplFileObject a SplFileInfo, přes adresáře je tu DirectoryIterator nebo RecursiveDirectoryIterator. S dokumentací je to u SPL tradičně slabší, takže doporučuji googlit. Sám jsem je nikdy nepoužil.

Že by měl ArrayObject vyhazovat výjimku jsem v dokumentaci nenašel. Samozřejmě se dá taková vlastnost snadno přidat do potomka třídy.

#8 jonsone, Díky za tipy :) , progooglím a podívám se na ně.

SPL snad jako jediné z core PHP vyhazuje výše uvedené výjimky a to proto, že implementace SPL ty výjimky obsahuje, pokud by nebylo SPL, nebudou tam asi ani ty výjimky.

Jinak „zobjetovateď“ nějakou core součást, tak to se týká nejen SPL ale třeba také DateTime nebo ZIPu, uvidíme, jak to bude dál pokračovat.

Jinak SPL je fakt pěkné, Marcus je maximalni borec, nicméně pokud vám jde o výkon, na SPL budete muset zapomenout, je to několikanásobně pomalejši než ekvivalentní procedurálni kód.

SPL bude asi jen objektový wrapper napsaný v céčku (pěkný protimluv).

Rád by som začal používať vyššie uvedené výnimky aj vo svojich kódoch, no zvykol som si vďaka svojmu frameworku na zápis výnimiek v asi takomto štýle:

throw new EException('Item', $item, 'was not found');
// co by teraz bolo asi
throw new OutOfBoundsException('Item '.$item.' was not found');

V čom je rozdiel? Pri renderovaní chybovej stránky mám to $item pekne zvýraznené (do <code>), kdežto ak by som používal OutOfBounds by sa mi hodnota $item opticky stratila v chybovej hláške. Je to blbina, ale moc som si na ňu zvykol. Ono by sa to dalo riešiť niečim ako spraviť si odvodený výnimku EOutOfBoundsException, ale to už nie je také elegantné. Nejaký nápad ako to inak riešiť, okrem prepísania php interpreta 😉?

Mě na Zend Frameworku nejvíce vadí, ze z Exception vzniklé během SQL dotazu nejde zjistit samotný SQL dotaz. Z důvodu logování SQL chyb.