Když Express vrací 500, middleware zachytí chybu dřív než uživatel
Selektory a normalizace d
Kdy si dát pozor na kombinace a slučitelno
Zapomeňte na to, že se agilní rituály dají dělat na dálku stejně jako naživo. Denní stand-up po videu je slabý odvar. Mnohem lepší je zavést dvě úrovně komunikace: krátký písemný update každé ráno a jednou týdně delší synchronizace se všemi. Písemný update nesmí být výčet činností, ale odpověď na tři otázky: co je hotové, co blokuje, co potřebuji od ostatních. Tím se předejde zbytečným schůzkám a zároveň vzniká dokumentace pro ty, kdo pracují v jiném čase.
API se vyvíjí a každá změna může rozbít to, co už funguje. Zaveďte verzování v cestě nebo v hlavičce a držte se ho. Když měníte tvar odpovědi nebo rušíte pole, nestačí o tom napsat do dokumentace. Oznámení musí proběhnout předem a klient musí mít čas se přizpůsobit. Zpětně kompatibilní změny, jako přidání nového pole, se dají dělat kdykoli. Odebrání nebo přejmenování pole je vždy změna, která potřebuje vlastní termín.
Asynchronní chyby neprojdou samy Nejčastější chyba je předpoklad, že Express zachytí zamítnutý promise z async funkce. Nezachytí. Když v async handleru selže await, výsledkem je unhandled rejection a Express o něm neví. Řešení jsou dvě. První je obalit každý handler pomocnou funkcí, která zavolá next(err) v catch bloku. Druhá je použít novější verzi Expressu, kde se asynchronní chyby předávají dál automaticky. Pokud zůstáváte na starší verzi, obal je nutnost, ne volba.
Simulace dat a vazeb v pra
Vlastní chybové třídy zpřehlední logiku. Vytvořte třídu AppError s polem statusCode a případně kódem pro klienta. V handleru pak házet new AppError(404, 'Uživatel nenalezen') místo ručního nastavování stavu. Chybový middleware rozliší AppError od neznámé chyby a podle toho zvolí odpověď. Neznámé chyby logujte s plným stackem, známé stačí krátce. Tím se vyhnete podmínkám rozesetým po celé aplikaci.
Poslední věc, kterou lidé podceňují, je návrat z chybového middleware. Jakmile odešlete odpověď, nechte funkci skončit. Volání next() po odeslání odpovědi vede k dalším handlerům a často k chybě o odeslaných hlavičkách. Stejně tak nedávejte chybový middleware do samostatného souboru bez exportu — zapomenutý modul znamená, že se nikdy nezaregistruje. Otestujte cestu chyby stejným způsobem jako cestu úspěchu, protože právě tam vznikají nejhorší produkční překvapení.
Výchozí chování Expressu při neošetřené chybě je tiché a matoucí: klient dostane prázdnou odpověď 500 a do konzole se vypíše stack trace. První krok k nápravě je pochopit, že Express prochází middleware v pořadí, v jakém byly zaregistrovány. Chybový middleware se pozná podle čtyř argumentů místo tří. Pokud funkci deklarujete se třemi parametry, Express ji bude považovat za běžný middleware a chybu nezachytí, i když ji pojmenujete ErrorHandler.
Stejně záludné jsou chyby v synchronním kódu, které proběhnou po odeslání odpovědi. Jakmile zavoláte res.send nebo res.json, hlavičky jsou odeslané a další pokus o odpověď vyhodí výjimku. V chybovém middleware proto vždy kontrolujte res.headersSent. Když už jsou hlavičky pryč, delegujte na výchozí handler přes next(err) a jen zalogujte. Pokus o res.status(500).json() po odeslání odpovědi shodí proces.
Základ je zaregistrovat chybový middleware až po všech routách a běžných middleware. Pořadí je kritické: když ho dáte před routy, Express se k němu při chybě z route nedostane. Funkce musí mít signaturu (err, req, res, next), i když next nepoužijete. Uvnitř logujte chybu serverově a klientovi posílejte jen to, co potřebuje — stavový kód a krátkou zprávu. Nikdy neposílejte stack trace do produkce, protože obsahuje cesty k souborům a verze závislostí.