Filtr chyb a výjimek pro Debugger

Přesně tak souhlasím s Filipem a prakticky si ani nedokáži představit, jak bys chtěl hodnotit vážnost chyby. Notice a warningy by být neměli resp. ty se odstraní již při vývoji a fataly a nezachycené vyjímky již sami o sobě jsou kritické. Ostatně i notice může být velice kritický z pohledu business logiky. Například takové:

<?php
$price = 1000; // Cena k platbě

$payment = new Payment();
$payment->setPrice($priceo); // Taková sranda, překlep - chyba úrovně notice a hned se nemusí platit
$payment->send();
?>

Tímto chci jen podotknout, že nelze definovat, co je chyba, která tě nemusí tolik pálit jako chyba, která ano.

Můžeš mi to prosím vysvětlit? Já to totiž nechápu. Protože tvůj hosting je k ničemu, tak budeš hackovat nette, aby se ti nelogovaly chyby, že se nejde připojit k databázi?

Už tohle je samo o sobě neskutečná hovadina.

Pokud ti jde jen o tohle, proč raději chybu neotchytáváš?

try {
	$this->db->connect();

} catch (\Exception $e) {
	die("Sorry, výpadek");
}

Já to vidím ještě trochu jinak. Myslím si, že mancze má dobrou myšlenku, i když v jeho případě bych taky jako první měnil hosting.

Proč logovat a nebo posílat na email každý výskyt chyby, o které vím, že mohou občas nastat. V tom případě bych bral chybu jako jeden z validních stavů aplikace. Stále se hodí logovat četnost i časy výskytu, ale nepotřebuji info na email, protože vím, že k ní občas z neovlivnitelných důvodů dojde, mám ji ošetřenou a informuji uživatele, ať to zkusí o chvíli později znovu (a nebo jinak – viz níže)

Myslím si, že vlastní ExceptionHandler může být v tomto případě také dobré řešení.
Logovat se stále dá „ručně“, zavoláním Debugger::log().

Ještě větší využití vidím v cron scriptech než ve skriptech generující výstupy na web, kdy vím že určité chyby mohu ignorovat, protože třeba o pár sekund nebo minut později se předchozí operace provede znovu a problém se „sám“ napraví.

Příklad:
Ještě jsem nedořešil podobný problém s tím, že externí API občas/nepravidelně 1–2× denně pár minut neodpovídá nebo vrací 500 response. Tyto chyby nechci logovat, ale chci to vyřešit tak, že cron job v tom případě bude opakovat poslední request až do doby kdy mu API odpoví. Ale jen v případě konkrétní chyby, kdy externí služba neodpovídá z důvodu zahlcení, údržby, apod.

Ostatní chyby se musí zpracovat standartně a normálně pokračovat s dalšími requesty a neopakovat neúspěšný request v případě, kdy nedostane správnou odpověď ze všech ostatních možných důvodů jako: nevalidní parametry, pokus o přístup k datům na které nemá oprávnění apod.

V mém případě by bylo hodně dobré neposílat informaci o sporadických výpadcích, ale jen o dlouhodobých.
Například vím že výpadek trvající do 2–5 minut je „běžný“ a mohu ho ignorovat.
Ale pokud výpadek trvá déle, může být důvod:

• problém na straně poskytovatel služby, na který bych ho měl upozornit
• změna API na kterou mne poskytovatel neupozornil
• vypršení platnosti přístupu na placené API
• update aplikace nebo změna konfigurace serveru a zanesení chyby, způsobující výpadky s větší četností než dříve
• nárust vytížení serveru a nutnost optimalizace nebo změny architektůry pro lepší škálovatelnost
• atd., atd.

a budu chtít info na email…

Podobně i databáze může být na pár chvil zahlcena, třeba proto že běží nějaké náročné údržbové skripty. Ale zas platí to, že logovat nebudu jen v případě, že požadovanou operaci budu dříve nebo později opakovat.

Jinak mám v kategorii todo „nice to have“ taky něco jako filtr na logy, ať je nemusím procházet ručně, ale řešil bych to asi vlastním loggerem. Taky se chci ještě inspirovat jak logování implementovali autoři composeru a jestli by se nedalo zakomponovat.

Ale to jsou všechno hodně specifické věci, byly by fajn jako rozšíření a přímo v nette být nemusí.

Editoval LeonardoCA (18. 1. 2013 0:19)

Neberu ti tvůj názor a díky za odkaz, bude se mi z toho ještě hodit.

Mě třeba štve, když se někde tvoří zbytečné data a proto je chci filtrovat už při ukládání.

Díky za vaše názory. Myslím, že LeonardoCA vyjádřil velice přesně podstatu problému. A má pravdu, CRON je jedním s případů, kde s tím bojuji. Já jsem nastínil případ výpadků databáze. Stává se mi to na dvou projektech. Jednou jde o lokální databázi a podruhé to je vzdálená databáze, nad kterou nemám kontrolu. Argumenty jako „změň hosting“ jsou sice hezké, ale v praxi to často nejde a tohle jeden z těch případů.

Filip Procházka napsal(a):

Od čeho je try {} catch () {}. Naučte se prosím „pořádně odchytávat chyby“…

Nenech se mýlit, try-catch používám a chyby mám ošetřené. Nevyřeší mi to ale problém s databází. Ta má lazy připojení, takže try-catch kolem connect() to dát nemůžu. I kdyby připojení nebylo líné, tak problém stejně zůstane – spojení mi může spadnout kdykoliv, nejen během připojování. A obalovat try-catch každý blok, kde se pracuje s databází – ne, děkuji, bohatě si vystačím s error 500, neřídím jadernou elektrárnu.

Panda napsal(a):

Výjimka a její „zpracování“ bude dost nelogicky odděleno od sebe a jak pak poznáš, že je to skutečně ta výjimka, co tě zajímá? Podle typu? Co když k výjimce stejného typu dojde ještě někde jinde v kódu? Budeš analyzovat stack trace? Co když pak v budoucnu při refactoringu třídy přeorganizuješ a na místě původní výjimky se bude vyhazovat podobná výjimka, která je však už mnohem vážnější?

Vlastně používám textovou zprávu výjimky pro rozlišení. O systematičnosti nepotřebuji nic slyšet, už tak celý mechanismus je jen berlička kvůli problémům neideálního prostředí reálného světa (to nepopírám). Pokud změní se text výjimky, ano, začnou mi zase chodit e-maily. No tak filtr upravím. Ale objektivně – to se téměř jistě nestane.

Panda napsal(a):

A co když filtr omylem zachytí zachytí zásadní výjimku, která narušuje konzistenci dat? Jak se o ní pak dozvíš?

To je pak problém špatně napsaného detekčního algoritmu filtru, ne jeho mechanismu.

Co mne ale po přečtení diskuze nenapadlo (a mělo napadnout), je napsat si try-catch kolem $application->run(). To by mi pak vyřešilo i odchytávání výjimek výpadku databáze. Pak bych nemusel obcházet exception handler Debuggeru. Poradí si to ale s případem, kdy má $application nastaveno catchExceptions = true?

Editoval mancze (18. 1. 2013 11:36)

Samotné odchytávání výjimek je určitě základ, ale to co chce mancze a výborně popsal LeonardoCA je naprosto logické a při správě většího počtu webů nutností. Výjimečné stavy se prostě stávají. Je nutné empiricky určit, kdy je lze zanedbat a kdy je nutné je reportovat a eskalovat (mail, SMS).

Nejsem si úplně jistý, jestli je správné takovýto monitoring dávat do aplikace. Myslím, že by bylo lepší poohlédnout se po nějakém řešení, které near real time analyzuje access log http serveru. Tím je možné odhalit i třeba chyby na statickém obsahu.