Háttér

Node.js hibakezelő rendszer felépítése

Nem nehéz belátni, hogy egyesek küzdenek a hibák kezelésével, sőt vannak, akiknek ez hiányzik is. A hibák megfelelő kezelése nem csupán a fejlesztési idő csökkentését jelenti a hibák és hibák könnyű megtalálásával, hanem a nagyméretű alkalmazások robusztus kódbázisának kifejlesztését is.

Különösen, Node.js fejlesztők néha nem túl tiszta kóddal dolgoznak, miközben különféle hibákat kezelnek, helytelenül alkalmazva ugyanazt a logikát mindenhol. Csak kérdezik maguktól 'A Node.js rosszul kezeli a hibákat?' vagy Ha nem, hogyan kezeljük őket? A válaszom az „Nem, a Node.js egyáltalán nem rossz. Ez rajtunk, fejlesztőkön múlik. ”

Íme az egyik kedvenc megoldásom erre.

A Node.js hibatípusai

Először is egyértelműen meg kell érteni a Node.js hibáit. Általában a Node.js hibákat két külön kategóriába sorolják: működési hibák és programozói hibák .

Működési hibák futásidejű problémákat jelentenek, amelyek várható eredményei és megfelelő módon kell kezelni őket. A működési hibák nem azt jelentik, hogy magában az alkalmazásban is vannak hibák, de a fejlesztőknek átgondoltan kell kezelniük őket. Példák a működési hibákra: „memória elfogyott”, „érvénytelen bemenet egy API végponthoz” stb.
Programozói hibák váratlan hibákat jelentenek rosszul írt kódban. Azt jelentik, hogy a kód maga is megoldandó kérdéseket tartalmaz, és hibásan lett kódolva. Jó példa arra, hogy megpróbálja elolvasni a „undefined” tulajdonságot. A probléma megoldásához meg kell változtatni a kódot. Ez egy fejlesztői hiba, nem pedig működési hiba.

Ezt szem előtt tartva nem lehet probléma a két hibakategória megkülönböztetésével: A működési hibák az alkalmazás természetes részét képezik, a programozói hibák pedig a fejlesztők által okozott hibák. A következő logikus kérdés a következő: 'Miért hasznos két kategóriába sorolni őket és foglalkozni velük?'

A hibák egyértelmű megértése nélkül előfordulhat, hogy hibát észlelve újraindítja az alkalmazást. Van-e értelme újraindítani egy alkalmazást a „Fájl nem található” hibák miatt, amikor több ezer felhasználó élvezi az alkalmazást? Egyáltalán nem.

De mi a helyzet a programozó hibáival? Van-e értelme egy alkalmazás futtatásának, ha ismeretlen hiba jelenik meg, amely váratlan hógolyó-hatást eredményezhet az alkalmazásban? Még egyszer, határozottan nem!

Itt az ideje a hibák megfelelő kezelésének

Feltéve, hogy van némi tapasztalata az async JavaScript és a Node.js használatával, előfordulhat, hogy hátrányokat tapasztal, amikor a visszahívásokat használja a hibák kezelésére. Kényszerítik, hogy ellenőrizze a hibákat egészen a beágyazottakig, ami hírhedt „visszahívási pokol” problémákat okoz, amelyek megnehezítik a kódfolyam követését.

Az ígéretek vagy az async / await használata jó helyettesíti a visszahívásokat. Az async / await tipikus kódfolyamata a következőképpen néz ki:

const doAsyncJobs = async () => { try { const result1 = await job1(); const result2 = await job2(result1); const result3 = await job3(result2); return await job4(result3); } catch (error) { console.error(error); } finally { await anywayDoThisJob(); } }

A Node.js beépített Error objektum használata jó gyakorlat, mert intuitív és világos információkat tartalmaz az olyan hibákról, mint a StackTrace, amelyektől a legtöbb fejlesztő függ, hogy nyomon kövesse a hiba gyökerét. A további jelentős tulajdonságok, például a HTTP állapotkód és a leírás a Hiba osztály kiterjesztésével informatívabbá teszik.

class BaseError extends Error { public readonly name: string; public readonly httpCode: HttpStatusCode; public readonly isOperational: boolean; constructor(name: string, httpCode: HttpStatusCode, description: string, isOperational: boolean) { super(description); Object.setPrototypeOf(this, new.target.prototype); this.name = name; this.httpCode = httpCode; this.isOperational = isOperational; Error.captureStackTrace(this); } } //free to extend the BaseError class APIError extends BaseError { constructor(name, httpCode = HttpStatusCode.INTERNAL_SERVER, isOperational = true, description = 'internal server error') { super(name, httpCode, isOperational, description); } }

Csak az egyszerűség kedvéért valósítottam meg néhány HTTP állapotkódot, de később szabadon hozzáadhat további adatokat.

export enum HttpStatusCode { OK = 200, BAD_REQUEST = 400, NOT_FOUND = 404, INTERNAL_SERVER = 500, }

Nincs szükség a BaseError vagy az APIError kiterjesztésére, de rendben van, hogy kiterjesszük a gyakori hibákra az Ön igényeinek és személyes preferenciáinak megfelelően.

class HTTP400Error extends BaseError { constructor(description = 'bad request') { super('NOT FOUND', HttpStatusCode.BAD_REQUEST, true, description); } }

Tehát hogyan használja? Csak dobd be ezt:

... const user = await User.getUserById(1); if (user === null) throw new APIError( 'NOT FOUND', HttpStatusCode.NOT_FOUND, true, 'detailed explanation' );

Központosított Node.js hibakezelés

Most készen állunk a Node.js hibakezelő rendszerünk fő összetevőjének felépítésére: a központosított hibakezelő komponensre.

Általában célszerű egy központosított hibakezelő komponenst felépíteni annak érdekében, hogy a hibák kezelésekor elkerülhető legyen az esetleges kódduplikálás. A hibakezelő komponens feladata, hogy a kifogott hibákat érthetővé tegye például azzal, hogy értesítéseket küld a rendszergazdáknak (ha szükséges), eseményeket továbbít egy olyan felügyeleti szolgáltatáshoz, mint a Sentry.io, és naplózza őket.

Itt van egy alapvető munkafolyamat a hibák kezeléséhez:

Hiba kezelése a Node.js fájlban: alapvető munkafolyamat

mit csinál a ruby on rails

A kód egyes részeiben hibákat észlelnek, hogy átkerüljenek egy hibakezelő köztes szoftverbe.

... try { userService.addNewUser(req.body).then((newUser: User) => { res.status(200).json(newUser); }).catch((error: Error) => { next(error) }); } catch (error) { next(error); } ...

A hibakezelő köztes szoftver alkalmas arra, hogy megkülönböztesse a hibatípusokat, és elküldje azokat a központosított hibakezelő komponensnek. A hibák kezelésének alapjainak ismerete Express.js köztes szoftver minden bizonnyal segítene.

app.use(async (err: Error, req: Request, res: Response, next: NextFunction) => { if (!errorHandler.isTrustedError(err)) { next(err); } await errorHandler.handleError(err); });

Mostanra el lehet képzelni, hogyan kell kinéznie a centralizált komponensnek, mert néhány funkcióját már használtuk. Ne feledje, hogy teljesen rajtad múlik, hogyan kell megvalósítani, de a következőképpen nézhet ki:

class ErrorHandler { public async handleError(err: Error): Promise { await logger.error( 'Error message from the centralized error-handling component', err, ); await sendMailToAdminIfCritical(); await sendEventsToSentry(); } public isTrustedError(error: Error) { if (error instanceof BaseError) { return error.isOperational; } return false; } } export const errorHandler = new ErrorHandler();

Néha az alapértelmezett „console.log” kimenete megnehezíti a hibák nyomon követését. Sokkal jobb lehet, ha a hibákat formázott formában nyomtatja ki, hogy a fejlesztők gyorsan megértsék a problémákat és meggyőződhessenek azok kijavításáról.

Összességében ez időt takarít meg a fejlesztőknek, megkönnyítve a hibák nyomon követését és kezelését a láthatóságuk növelésével. Jó döntés testreszabható naplózót használni winston vagy morgan .

Itt van egy testreszabott Winston naplózó:

hogyan lehet feltörni a hitelkártya PIN-kódját

const customLevels = { levels: { trace: 5, debug: 4, info: 3, warn: 2, error: 1, fatal: 0, }, colors: { trace: 'white', debug: 'green', info: 'green', warn: 'yellow', error: 'red', fatal: 'red', }, }; const formatter = winston.format.combine( winston.format.colorize(), winston.format.timestamp({ format: 'YYYY-MM-DD HH:mm:ss' }), winston.format.splat(), winston.format.printf((info) => { const { timestamp, level, message, ...meta } = info; return `${timestamp} [${level}]: ${message} ${ Object.keys(meta).length ? JSON.stringify(meta, null, 2) : '' }`; }), ); class Logger { private logger: winston.Logger; constructor() { const prodTransport = new winston.transports.File({ filename: 'logs/error.log', level: 'error', }); const transport = new winston.transports.Console({ format: formatter, }); this.logger = winston.createLogger({ level: isDevEnvironment() ? 'trace' : 'error', levels: customLevels.levels, transports: [isDevEnvironment() ? transport : prodTransport], }); winston.addColors(customLevels.colors); } trace(msg: any, meta?: any) { this.logger.log('trace', msg, meta); } debug(msg: any, meta?: any) { this.logger.debug(msg, meta); } info(msg: any, meta?: any) { this.logger.info(msg, meta); } warn(msg: any, meta?: any) { this.logger.warn(msg, meta); } error(msg: any, meta?: any) { this.logger.error(msg, meta); } fatal(msg: any, meta?: any) { this.logger.log('fatal', msg, meta); } } export const logger = new Logger();

Amit alapvetően nyújt, az az, hogy naplózni több különböző szinten, formázott módon, tiszta színekkel, és bejelentkezni a különböző kimeneti adathordozókba a futásidejű környezetnek megfelelően. Ezzel az a jó, hogy a Winston beépített API-jainak használatával megtekintheti és lekérdezheti a naplókat. Ezenkívül naplóelemző eszközzel elemezheti a formázott naplófájlokat, így hasznosabb információkat kaphat az alkalmazásról. Félelmetes, nem?

Eddig a pontig leginkább a működési hibák kezeléséről tárgyaltunk. Mit szólnál a programozó hibáihoz? A hibák kezelésének legjobb módja az azonnali összeomlás és az automatikus újraindítás, például a PM2 - újraindítása - ennek oka az, hogy a programozói hibák váratlanok, mivel ezek tényleges hibák, amelyek miatt az alkalmazás rossz állapotba kerülhet és viselkedhet váratlan módon.

process.on('uncaughtException', (error: Error) => { errorHandler.handleError(error); if (!errorHandler.isTrustedError(error)) { process.exit(1); } });

Végül, de nem utolsósorban megemlítem a kezeletlen ígéretek elutasítását és kivételeket.

Előfordulhat, hogy sok időt tölt az ígéretekkel, amikor a Node.js / Express alkalmazásokon dolgozik. Nem nehéz figyelmeztető üzeneteket látni a nem kezelt ígéretek elutasításáról, amikor elfelejtjük kezelni az elutasításokat.

A figyelmeztető üzenetek a naplózáson kívül nem sokat tesznek, de jó gyakorlat a megfelelő tartalék használata és a process.on(‘unhandledRejection’, callback) feliratkozás.

A tipikus hibakezelési folyamat a következőképpen nézhet ki:

// somewhere in the code ... User.getUserById(1).then((firstUser) => { if (firstUser.isSleeping === false) throw new Error('He is not sleeping!'); }); ... // get the unhandled rejection and throw it to another fallback handler we already have. process.on('unhandledRejection', (reason: Error, promise: Promise) => { throw reason; }); process.on('uncaughtException', (error: Error) => { errorHandler.handleError(error); if (!errorHandler.isTrustedError(error)) { process.exit(1); } });

Csomagolás

Ha mindent elmondott és kész, akkor rá kell döbbennie, hogy a hibakezelés nem opcionális extra, hanem az alkalmazás elengedhetetlen része, mind a fejlesztési szakaszban, mind a gyártásban.

A Node.js egyetlen összetevőjében a hibák kezelésének stratégiája biztosítja a fejlesztők számára, hogy értékes időt takarítsanak meg, és tiszta és karbantartható kódot írjanak a kód duplikációjának és a hibakörnyezet hiányának elkerülése révén.

Remélem, hogy tetszett olvasni ezt a cikket, és a megbeszélt hibakezelési munkafolyamatot és megvalósítást hasznosnak találta a robusztus kódbázis a Node.js fájlban .

Az alapok megértése

Miért fontos a hibakezelés?

A megfelelő hibakezelés az alkalmazásokat robusztusvá teszi, amely kiváló felhasználói élményt és jobb termelékenységet eredményez.

Milyen stratégiákat vagy technikákat használnak a hibakezeléshez?

Az ígéretek vagy az async / várakozás használata, a hibák kezelése központosított összetevőben, az el nem fogott kivételek kezelése.

Miért van szükség hibakezelésre?

A hibakezelés az összes alkalmazás kötelező része. Megakadályozza, hogy az alkalmazások hibára hajlamosak legyenek, és értékes fejlesztési időt takarít meg.