\n Express.js uygulamalar\u0131n\u0131zda hata y\u00f6netimini nas\u0131l basitle\u015ftirebilir, tek bir k\u00fct\u00fcphane ile tutarl\u0131 ve \u00f6l\u00e7eklenebilir bir yap\u0131ya kavu\u015fturabilirsiniz? Modern bir Node.js projesinde kar\u015f\u0131la\u015fabilece\u011finiz en yayg\u0131n sorunlardan biri olan karma\u015f\u0131k ve da\u011f\u0131n\u0131k hata yakalama s\u00fcre\u00e7lerini bu detayl\u0131 rehberle ortadan kald\u0131r\u0131n.\n <\/p>\n
\n Express.js ile geli\u015ftirme yaparken, hatalar\u0131n y\u00f6netimi genellikle geli\u015ftiricilerin kar\u015f\u0131la\u015ft\u0131\u011f\u0131 ilk ciddi engellerden biridir. Yeni ba\u015flayanlar i\u00e7in kafa kar\u0131\u015ft\u0131r\u0131c\u0131 olabilen bu s\u00fcre\u00e7, deneyimli geli\u015ftiriciler i\u00e7in bile b\u00fcy\u00fck \u00f6l\u00e7ekli uygulamalarda tutars\u0131zl\u0131k ve bak\u0131m zorluklar\u0131na yol a\u00e7abilir. Projeler b\u00fcy\u00fcd\u00fck\u00e7e, farkl\u0131 mod\u00fcller, asenkron i\u015flemler ve \u00fc\u00e7\u00fcnc\u00fc parti entegrasyonlar nedeniyle hata y\u00f6netimi adeta bir labirente d\u00f6n\u00fc\u015febilir. Her geli\u015ftiricinin kendi y\u00f6ntemini kullanmas\u0131 veya hatalar\u0131 gerekti\u011fi gibi yakalamamas\u0131, uygulaman\u0131n genel g\u00fcvenilirli\u011fini ve kullan\u0131c\u0131 deneyimini do\u011frudan etkiler. \u00d6zellikle asenkron operasyonlar, callback’ler, Promise’ler veya async\/await yap\u0131lar\u0131 devreye girdi\u011finde, hatalar\u0131n beklenen \u015fekilde yakalan\u0131p i\u015flenmesi daha da zorla\u015f\u0131r. Genellikle hatalar g\u00f6zden ka\u00e7ar, uygulamay\u0131 beklenmedik \u015fekilde \u00e7\u00f6kertir veya kullan\u0131c\u0131ya anlams\u0131z, teknik detaylar i\u00e7eren hata mesajlar\u0131 sunar. Bu durum, sadece geli\u015ftirme s\u00fcrecini yava\u015flatmakla kalmaz, ayn\u0131 zamanda son kullan\u0131c\u0131n\u0131n kar\u015f\u0131s\u0131na \u00e7\u0131kan belirsiz ve anla\u015f\u0131lmaz hata mesajlar\u0131 y\u00fcz\u00fcnden uygulaman\u0131n profesyonelli\u011fine de g\u00f6lge d\u00fc\u015f\u00fcr\u00fcr.\n <\/p>\n
\n Diyelim ki bir e-ticaret uygulamas\u0131n\u0131n geli\u015ftirme ekibindesiniz. \u00d6deme i\u015flemleri, \u00fcr\u00fcn stok g\u00fcncellemeleri, kullan\u0131c\u0131 kimlik do\u011frulamas\u0131 gibi kritik operasyonlar\u0131n her biri asenkron \u00e7a\u011fr\u0131lar i\u00e7erir. Kullan\u0131c\u0131 bir \u00fcr\u00fcn sat\u0131n al\u0131rken, arka planda stok d\u00fc\u015f\u00fcl\u00fcrken bir veritaban\u0131 ba\u011flant\u0131 hatas\u0131 ya\u015fand\u0131\u011f\u0131nda, bu hatan\u0131n do\u011fru bir \u015fekilde yakalan\u0131p kullan\u0131c\u0131ya “\u00d6deme i\u015flemi ba\u015far\u0131s\u0131z oldu, l\u00fctfen tekrar deneyin” gibi anla\u015f\u0131l\u0131r bir mesajla sunulmas\u0131 hayati \u00f6nem ta\u015f\u0131r. Ancak \u00e7o\u011fu zaman, bu senaryolarda ya hi\u00e7 hata yakalanmaz ve uygulama sessizce \u00e7\u00f6ker ya da kullan\u0131c\u0131ya do\u011frudan veritaban\u0131 hatas\u0131n\u0131n teknik detaylar\u0131 g\u00f6sterilir ki bu hem g\u00fcvenlik hem de kullan\u0131c\u0131 deneyimi a\u00e7\u0131s\u0131ndan kabul edilemez bir durumdur. \u0130\u015fte bu noktada, standartla\u015ft\u0131r\u0131lm\u0131\u015f bir hata y\u00f6netim yakla\u015f\u0131m\u0131na ihtiya\u00e7 duyar\u0131z.\n <\/p>\n
\n Peki, bu karma\u015f\u0131kl\u0131\u011f\u0131n temel nedenleri nelerdir? \u0130lk olarak, Express.js’in hata y\u00f6netim mekanizmas\u0131, geleneksel senkron kodda \n Express.js’in g\u00fc\u00e7l\u00fc yan\u0131, middleware tabanl\u0131 yap\u0131s\u0131d\u0131r. Bu yap\u0131, hem gelen istekleri i\u015flemek hem de hatalar\u0131 yakalamak i\u00e7in esnek bir mekanizma sunar. Ancak, bu esnekli\u011fin do\u011fru anla\u015f\u0131lmas\u0131 ve uygulanmas\u0131 kritik \u00f6neme sahiptir. Express.js’te temel olarak \u00fc\u00e7 farkl\u0131 hata yakalama mekanizmas\u0131 bulunur: Varsay\u0131lan Hata \u0130\u015fleyicisi, \u00d6zel Hata \u0130\u015fleyici Middleware’leri ve Asenkron Hata Y\u00f6netimi.\n <\/p>\n \n Varsay\u0131lan Hata \u0130\u015fleyicisi:<\/strong> Express.js, herhangi bir \u00f6zel hata i\u015fleyici tan\u0131mlanmad\u0131\u011f\u0131nda otomatik olarak bir varsay\u0131lan hata i\u015fleyicisine sahiptir. E\u011fer bir middleware i\u00e7inde \n \u00d6zel Hata \u0130\u015fleyici Middleware’leri:<\/strong> Express.js’te \u00f6zel hata i\u015fleyicileri, normal middleware’lerden farkl\u0131 bir imza ta\u015f\u0131r: <\/code><\/p>\n \n Bu yap\u0131land\u0131rmada, hem senkron olarak f\u0131rlat\u0131lan hatalar ( \n Asenkron Hata Y\u00f6netimi:<\/strong> Express.js'in varsay\u0131lan hata i\u015fleme mekanizmas\u0131, middleware'ler veya rotalar i\u00e7inde senkron olarak f\u0131rlat\u0131lan hatalar\u0131 yakalamakta etkilidir. Ancak, Promise'ler veya async\/await gibi asenkron yap\u0131lar i\u00e7inde meydana gelen hatalar do\u011frudan bu mekanizma taraf\u0131ndan yakalanmaz. Bir Promise reddedildi\u011finde veya bir async fonksiyon i\u00e7inde bir hata f\u0131rlat\u0131ld\u0131\u011f\u0131nda ve bu hata bir \n \n Express.js'te geleneksel hata y\u00f6netimi yakla\u015f\u0131mlar\u0131, \u00f6zellikle projenin karma\u015f\u0131kl\u0131\u011f\u0131 ve boyutu artt\u0131k\u00e7a bir\u00e7ok eksikli\u011fi ortaya \u00e7\u0131kar\u0131r. Bu eksiklikler, hem geli\u015ftirme verimlili\u011fini d\u00fc\u015f\u00fcr\u00fcr hem de uygulaman\u0131n genel g\u00fcvenilirli\u011fini tehlikeye atar. Temel olarak, bu sorunlar kod tekrar\u0131, asenkron hatalar\u0131n yanl\u0131\u015f y\u00f6netimi ve tutars\u0131z hata yan\u0131tlar\u0131 olmak \u00fczere \u00fc\u00e7 ana ba\u015fl\u0131k alt\u0131nda toplanabilir.\n <\/p>\n \n Kod Tekrar\u0131 ve Bak\u0131m Zorlu\u011fu:<\/strong> Her rota i\u015fleyicisi veya middleware i\u00e7inde <\/code><\/p>\n \n Yukar\u0131daki \u00f6rnekte de g\u00f6r\u00fcld\u00fc\u011f\u00fc gibi, her bir rota i\u015fleyicisi i\u00e7inde benzer hata yakalama mant\u0131\u011f\u0131n\u0131 tekrar tekrar yazmak zorunda kal\u0131r\u0131z. Bu, hem zaman kayb\u0131na hem de kodun \u015fi\u015fmesine neden olur.\n <\/p>\n \n Asenkron Hatalar\u0131n Yanl\u0131\u015f Y\u00f6netimi:<\/strong> Express.js'in do\u011fal hata i\u015fleme mekanizmas\u0131, asenkron kodda meydana gelen ve do\u011fru bir \u015fekilde <\/code><\/p>\n \n Bu senaryo, uygulaman\u0131n kararl\u0131l\u0131\u011f\u0131 i\u00e7in ciddi bir risk olu\u015fturur. Geli\u015ftiricilerin her asenkron i\u015flemi manuel olarak sarmalamas\u0131 gerekti\u011fi anlam\u0131na gelir ki bu da b\u00fcy\u00fck ve karma\u015f\u0131k uygulamalarda s\u00fcrd\u00fcr\u00fclemez bir y\u00fckt\u00fcr.\n <\/p>\n \n Tutars\u0131z Hata Yan\u0131tlar\u0131:<\/strong> Farkl\u0131 geli\u015ftiriciler veya farkl\u0131 mod\u00fcller, ayn\u0131 tipte bir hata i\u00e7in farkl\u0131 HTTP durum kodlar\u0131, hata mesajlar\u0131 veya JSON yap\u0131lar\u0131 d\u00f6nd\u00fcrebilir. Bu tutars\u0131zl\u0131k, istemci taraf\u0131 uygulamalar\u0131n (mobil uygulamalar, web \u00f6n y\u00fczleri) bu hatalar\u0131 do\u011fru bir \u015fekilde i\u015flemesini zorla\u015ft\u0131r\u0131r. \u00d6rne\u011fin, bir oturum a\u00e7ma hatas\u0131 bazen 401 Unauthorized, bazen 403 Forbidden, bazen de 500 Internal Server Error olarak d\u00f6nebilir. Bu durum, istemci taraf\u0131nda her olas\u0131 hata senaryosu i\u00e7in ayr\u0131 ayr\u0131 i\u015fleme mant\u0131\u011f\u0131 yazmay\u0131 gerektirir ve hata ay\u0131klama s\u00fcrecini kabusa \u00e7evirir. Standardize edilmi\u015f bir hata yap\u0131s\u0131 olmad\u0131\u011f\u0131nda, hata mesajlar\u0131 kullan\u0131c\u0131ya anlams\u0131z \"internal server error\" metinlerinden, veritaban\u0131 sorgu hatalar\u0131n\u0131n teknik detaylar\u0131na kadar de\u011fi\u015febilir, bu da hem g\u00fcvenlik zafiyetleri yarat\u0131r hem de k\u00f6t\u00fc bir kullan\u0131c\u0131 deneyimine yol a\u00e7ar. Bu problemleri \u00e7\u00f6zmek i\u00e7in, tek bir k\u00fct\u00fcphane etraf\u0131nda birle\u015fen ve \u00f6zel hata s\u0131n\u0131flar\u0131yla desteklenen standartla\u015ft\u0131r\u0131lm\u0131\u015f bir yakla\u015f\u0131m benimsemek elzemdir.\n <\/p>\n \n Express.js'te asenkron hatalar\u0131n manuel olarak \n \n Kurulum ve Kullan\u0131m:<\/strong> <\/code><\/p>\n \n Kurulumdan sonra, yapman\u0131z gereken tek \u015fey, Express.js uygulaman\u0131z\u0131n ana dosyas\u0131nda (genellikle <\/code><\/p>\n \n Yukar\u0131daki \u00f6rnekte, \n \n \n \u00d6zel hata s\u0131n\u0131flar\u0131, uygulaman\u0131zdaki farkl\u0131 hata senaryolar\u0131n\u0131 (\u00f6rne\u011fin, do\u011frulama hatas\u0131, yetkilendirme hatas\u0131, kaynak bulunamad\u0131 hatas\u0131) temsil etmek i\u00e7in kendi hata nesnelerinizi olu\u015fturman\u0131za olanak tan\u0131r. Bu sayede, her hata t\u00fcr\u00fc i\u00e7in tutarl\u0131 bir yap\u0131 ve belirli \u00f6zellikler (HTTP durum kodu, kullan\u0131c\u0131 dostu mesaj, log mesaj\u0131 vb.) tan\u0131mlayabilirsiniz.\n <\/p>\n \n \u00d6zel Hata S\u0131n\u0131flar\u0131 Kullanman\u0131n Avantajlar\u0131:<\/strong>\n <\/p>\n \n Uygulamam\u0131z i\u00e7in bir temel <\/code><\/p>\n \n Bu temel <\/code><\/p>\n \n Art\u0131k rotalar\u0131m\u0131zda veya servis katmanlar\u0131m\u0131zda, \n \u015eimdiye kadar, asenkron hatalar\u0131 \n Uygulamam\u0131zdaki t\u00fcm hatalar\u0131 yakalay\u0131p i\u015fleyecek merkezi bir hata y\u00f6netim middleware'ine ihtiyac\u0131m\u0131z var. Bu middleware, <\/code><\/p>\n \n Bu \n \u015eimdi, <\/code><\/p>\n \n Yukar\u0131daki kodda, \n Art\u0131k her bir rotan\u0131zda \n Bir e-ticaret platformunun API geli\u015ftirme ekibinde \u00e7al\u0131\u015ft\u0131\u011f\u0131m\u0131z\u0131 hayal edelim. Proje, y\u00fczlerce farkl\u0131 API u\u00e7 noktas\u0131na, mikroservislere ve \u00fc\u00e7\u00fcnc\u00fc parti entegrasyonlara sahipti. \u0130lk ba\u015flarda, her geli\u015ftirici kendi bildi\u011fi \u015fekilde hata y\u00f6netimi yap\u0131yordu. Kimi zaman \n Ekip, bu problemleri \u00e7\u00f6zmek i\u00e7in kapsaml\u0131 bir standartla\u015ft\u0131rma projesi ba\u015flatt\u0131 ve bu makalede ele ald\u0131\u011f\u0131m\u0131z yakla\u015f\u0131m\u0131 benimsedi:\n <\/p>\n \n Bu d\u00f6n\u00fc\u015f\u00fcm\u00fcn ard\u0131ndan, e-ticaret platformunun hata y\u00f6netimi tamamen de\u011fi\u015fti:\n <\/p>\n \n Bu vaka analizi, tek bir k\u00fct\u00fcphane ve \u00f6zel hata s\u0131n\u0131flar\u0131 gibi standart bir yakla\u015f\u0131m\u0131n, b\u00fcy\u00fck \u00f6l\u00e7ekli ve karma\u015f\u0131k Express.js uygulamalar\u0131nda hata y\u00f6netimini nas\u0131l radikal bir \u015fekilde iyile\u015ftirebilece\u011fini a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Bu, sadece teknik bir iyile\u015ftirme olman\u0131n \u00f6tesinde, t\u00fcm geli\u015ftirme ekibinin verimlili\u011fini ve \u00fcr\u00fcn\u00fcn genel kalitesini art\u0131ran stratejik bir ad\u0131md\u0131r.\n <\/p>\n \n Express.js uygulaman\u0131zda standartla\u015ft\u0131r\u0131lm\u0131\u015f bir hata y\u00f6netim sistemi kurmak harika bir ba\u015flang\u0131\u00e7t\u0131r. Ancak, ger\u00e7ek d\u00fcnya senaryolar\u0131nda, sadece hatalar\u0131 yakalamak ve istemciye yan\u0131t vermek yeterli de\u011fildir. Hatalar\u0131 detayl\u0131 bir \u015fekilde loglamak, izlemek ve hatta kullan\u0131c\u0131 dostu hata sayfalar\u0131 sunmak, uygulaman\u0131z\u0131n dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 ve kullan\u0131c\u0131 deneyimini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. Bu b\u00f6l\u00fcmde, bu ileri d\u00fczey stratejileri ve ipu\u00e7lar\u0131n\u0131 ele alaca\u011f\u0131z.\n <\/p>\n \n \n <\/code><\/p>\n <\/code> const errorHandler = (err, req, res, next) => { \/\/ Winston ile loglama res.status(error.statusCode || 500).json({ module.exports = errorHandler; \n Bu yap\u0131land\u0131rma, hatalar\u0131n daha kapsaml\u0131 ve yap\u0131sal bir \u015fekilde loglanmas\u0131n\u0131 sa\u011flar. B\u00f6ylece, hata ay\u0131klama s\u00fcre\u00e7leri h\u0131zlan\u0131r ve \u00fcretim ortam\u0131ndaki sorunlar\u0131 daha kolay tespit edebilirsiniz.\n <\/p>\n \n Hata \u0130zleme Ara\u00e7lar\u0131 (APM):<\/strong> Sentry, Bugsnag veya New Relic gibi Application Performance Monitoring (APM) ara\u00e7lar\u0131, hatalar\u0131 ger\u00e7ek zamanl\u0131 olarak izlemenizi, bildirim alman\u0131z\u0131 ve hata izlerini (stack trace) detayl\u0131 bir \u015fekilde g\u00f6rmenizi sa\u011flar. Bu ara\u00e7lar\u0131 \n API'lerde hata y\u00f6netimi genellikle JSON yan\u0131tlar\u0131yla s\u0131n\u0131rl\u0131 olsa da, web uygulamalar\u0131nda veya \u00f6zel durumlarda (\u00f6rne\u011fin, 404 Not Found sayfalar\u0131, genel 500 hatalar\u0131) kullan\u0131c\u0131ya g\u00f6sterilen hata sayfalar\u0131 da \u00f6nemlidir. Bu sayfalar\u0131n sadece estetik de\u011fil, ayn\u0131 zamanda mobil uyumlu ve bilgilendirici olmas\u0131 gerekir.\n <\/p>\n \n Basit bir HTML hata sayfas\u0131 \u00f6rne\u011fi ve CSS ile mobil uyumlulu\u011fu:\n <\/p>\ntry-catch<\/code> bloklar\u0131yla al\u0131\u015fk\u0131n oldu\u011fumuzdan farkl\u0131 i\u015fler. Middleware zincirleri i\u00e7inde, bir hata meydana geldi\u011finde bunu next(err)<\/code> \u00e7a\u011fr\u0131s\u0131 ile bir sonraki hata yakalay\u0131c\u0131 middleware’e iletmeniz gerekir. Ancak bu, asenkron i\u015flemlerde kolayca unutulabilir veya yanl\u0131\u015f uygulanabilir. \u0130kinci olarak, her hata t\u00fcr\u00fc i\u00e7in ayr\u0131 ayr\u0131 if-else bloklar\u0131 yazmak veya farkl\u0131 HTTP durum kodlar\u0131 d\u00f6nd\u00fcrmek, kod tekrar\u0131na ve okunabilirli\u011fi d\u00fc\u015f\u00fcren bir yap\u0131ya yol a\u00e7ar. \u00d6rne\u011fin, bir kimlik do\u011frulama hatas\u0131 (401 Unauthorized), bir kaynak bulunamad\u0131 hatas\u0131 (404 Not Found) veya bir sunucu hatas\u0131 (500 Internal Server Error) i\u00e7in ayr\u0131 ayr\u0131 yan\u0131tlar olu\u015fturmak, zamanla s\u00fcrd\u00fcr\u00fclemez hale gelir. Son olarak, loglama, izleme ve kullan\u0131c\u0131ya g\u00f6sterilecek mesajlar\u0131n standartla\u015ft\u0131r\u0131lmas\u0131 da her zaman g\u00f6z ard\u0131 edilen bir detayd\u0131r. Bu makalede, bu zorluklar\u0131 a\u015fmak ve Express.js uygulamalar\u0131n\u0131zda hata y\u00f6netimini tek bir yakla\u015f\u0131m etraf\u0131nda birle\u015ftirmek i\u00e7in g\u00fc\u00e7l\u00fc bir k\u00fct\u00fcphane ve yap\u0131sal \u00e7\u00f6z\u00fcmleri ele alaca\u011f\u0131z. Amac\u0131m\u0131z, uygulaman\u0131z\u0131n daha sa\u011flam, g\u00fcvenilir ve bak\u0131m\u0131 kolay olmas\u0131n\u0131 sa\u011flamakt\u0131r.\n <\/p>\nTemel Kavramlar: Express.js Hata Yakalama Mekanizmalar\u0131 Nelerdir?<\/h2>\n
next(err)<\/code> \u00e7a\u011fr\u0131s\u0131 yap\u0131l\u0131r ve bu hatay\u0131 yakalayacak ba\u015fka bir hata i\u015fleyici middleware yoksa, Express.js bu varsay\u0131lan i\u015fleyiciyi devreye sokar. Bu varsay\u0131lan i\u015fleyici, genellikle hata mesaj\u0131n\u0131 konsola basar ve istemciye bir 500 Internal Server Error yan\u0131t\u0131 g\u00f6nderir. Ancak bu yan\u0131t, \u00fcretim ortam\u0131nda kullan\u0131c\u0131ya g\u00f6sterilmemesi gereken hassas bilgiler i\u00e7erebilir. Dolay\u0131s\u0131yla, ciddi uygulamalarda her zaman \u00f6zel bir hata i\u015fleyici tan\u0131mlamak en iyi pratiktir.\n <\/p>\n(err, req, res, next)<\/code>. \u0130lk parametre olan err<\/code>, \u00f6nceki middleware’lerden next(err)<\/code> arac\u0131l\u0131\u011f\u0131yla iletilen hata nesnesidir. Bu \u00f6zel middleware’leri, uygulaman\u0131z\u0131n en sonunda, t\u00fcm rotalar\u0131n\u0131zdan ve di\u011fer middleware’lerden sonra tan\u0131mlars\u0131n\u0131z. Bu sayede, uygulaman\u0131z\u0131n herhangi bir noktas\u0131nda f\u0131rlat\u0131lan veya next(err)<\/code> ile iletilen her t\u00fcrl\u00fc hatay\u0131 merkezi bir yerden yakalay\u0131p i\u015fleyebilirsiniz. \u0130\u015fte basit bir \u00f6rnek:\n <\/p>\n\nconst app = require('express')();\n\napp.get('\/', (req, res) => {\n throw new Error('Senkron bir hata!'); \/\/ Senkron hata f\u0131rlatma\n});\n\napp.get('\/async-fail', (req, res, next) => {\n \/\/ Asenkron bir i\u015flem sim\u00fcle edelim\n setTimeout(() => {\n try {\n \/\/ Hata yakalanmazsa Express'e ula\u015fmaz\n throw new Error('Asenkron bir hata!');\n } catch (err) {\n next(err); \/\/ next(err) ile hata yakalama middleware'ine iletme\n }\n }, 100);\n});\n\n\/\/ \u00d6zel hata i\u015fleyici middleware\napp.use((err, req, res, next) => {\n console.error(err.stack); \/\/ Hata detaylar\u0131n\u0131 logla\n res.status(500).send('Sunucu taraf\u0131nda bir hata olu\u015ftu!'); \/\/ Kullan\u0131c\u0131ya dost\u00e7a mesaj\n});\n\napp.listen(3000, () => {\n console.log('Sunucu 3000 portunda \u00e7al\u0131\u015f\u0131yor...');\n});\n <\/pre>\nthrow new Error<\/code>) hem de asenkron olarak f\u0131rlat\u0131l\u0131p next(err)<\/code> ile iletilen hatalar, son app.use((err, req, res, next) => ...)<\/code> blokuna ula\u015f\u0131r. Bu, hatalar\u0131 tek bir noktadan y\u00f6netmek i\u00e7in g\u00fc\u00e7l\u00fc bir temel sa\u011flar.\n <\/p>\ntry-catch<\/code> blo\u011fu i\u00e7inde yakalanmazsa, Express.js'in middleware zinciri bu hatadan haberdar olmaz. Bu t\u00fcr durumlar genellikle uygulaman\u0131n \"unutulmu\u015f\" bir hatayla \u00e7\u00f6kmesine veya beklenmedik davran\u0131\u015flar sergilemesine neden olur. Bu durumlar\u0131n \u00f6n\u00fcne ge\u00e7mek i\u00e7in her asenkron \u00e7a\u011fr\u0131n\u0131n sonucunu manuel olarak yakalay\u0131p next(err)<\/code> ile hata i\u015fleyiciye iletmek gerekir ki bu da ciddi kod tekrar\u0131na ve okunabilirli\u011fin azalmas\u0131na yol a\u00e7ar. \u0130\u015fte bu noktada, tek bir k\u00fct\u00fcphane ile bu asenkron hatalar\u0131 otomatik olarak yakalama ihtiyac\u0131 do\u011far, ki sonraki b\u00f6l\u00fcmlerde buna detayl\u0131ca de\u011finece\u011fiz.\n <\/p>\n
\n Uzman \u0130pucu: Hata i\u015fleyici middleware'inizi her zaman di\u011fer t\u00fcm app.use()<\/code> ve app.get()<\/code>\/app.post()<\/code> gibi rota tan\u0131mlamalar\u0131ndan sonra yerle\u015ftirin. Aksi takdirde, hata yakalama zinciri bekledi\u011finiz gibi \u00e7al\u0131\u015fmayabilir.
\n <\/span>\n <\/p>\nProblemin K\u00f6kleri: Geleneksel Y\u00f6ntemlerin Eksiklikleri Nelerdir?<\/h2>\n
try-catch<\/code> bloklar\u0131 kullanmak, kodu gereksiz yere uzat\u0131r ve okunabilirli\u011fi azalt\u0131r. \u00d6zellikle Promise tabanl\u0131 asenkron fonksiyonlarla \u00e7al\u0131\u015f\u0131rken, her await<\/code> ifadesini bir try-catch<\/code> i\u00e7ine almak veya her Promise i\u00e7in .catch()<\/code> metodunu eklemek zorunlulu\u011fu, \u00e7ok say\u0131da boilerplate koduna yol a\u00e7ar. Bu durum, bir hata tipi de\u011fi\u015fti\u011finde veya hata i\u015fleme mant\u0131\u011f\u0131 g\u00fcncellenmesi gerekti\u011finde, uygulaman\u0131n farkl\u0131 yerlerinde onlarca, hatta y\u00fczlerce try-catch<\/code> blo\u011funu g\u00fcncelleme ihtiyac\u0131 do\u011furur. Bu t\u00fcr manuel g\u00fcncellemeler, hatalara ve insan fakt\u00f6r\u00fcne dayal\u0131 eksikliklere a\u00e7\u0131kt\u0131r. \u00d6rne\u011fin, bir geli\u015ftiricinin belirli bir rotada next(err)<\/code>'yi unutmas\u0131, uygulaman\u0131n \u00e7\u00f6kmesine veya hata yakalay\u0131c\u0131 middleware'e ula\u015famamas\u0131na neden olabilir.\n <\/p>\n\n\/\/ Geleneksel Y\u00f6ntemde Kod Tekrar\u0131 \u00d6rne\u011fi\napp.get('\/kullanici\/:id', async (req, res, next) => {\n try {\n const user = await UserService.getUserById(req.params.id);\n if (!user) {\n return res.status(404).json({ message: 'Kullan\u0131c\u0131 bulunamad\u0131.' });\n }\n res.json(user);\n } catch (error) {\n console.error('Kullan\u0131c\u0131 alma hatas\u0131:', error.message);\n next(error); \/\/ Hata yakalay\u0131c\u0131ya iletme\n }\n});\n\napp.post('\/urunler', async (req, res, next) => {\n try {\n const product = await ProductService.createProduct(req.body);\n res.status(201).json(product);\n } catch (error) {\n console.error('\u00dcr\u00fcn olu\u015fturma hatas\u0131:', error.message);\n next(error); \/\/ Yine next(error)\n }\n});\n <\/pre>\nnext(err)<\/code> ile iletilmeyen hatalar\u0131 otomatik olarak yakalamaz. \u00d6zellikle Promise'ler veya async\/await<\/code> yap\u0131lar\u0131 kullan\u0131l\u0131rken, e\u011fer bir try-catch<\/code> blo\u011fu veya .catch()<\/code> zinciri eksikse, bir Promise reddedildi\u011finde bu hata Express.js'in middleware zincirinin d\u0131\u015f\u0131na \u00e7\u0131kar ve uygulaman\u0131n tamamen \u00e7\u00f6kmesine neden olan \"unhandled promise rejection\" hatalar\u0131na yol a\u00e7ar. Bu t\u00fcr hatalar, uygulamay\u0131 karars\u0131z hale getirir ve \u00f6zellikle yo\u011fun trafik alt\u0131nda \u00f6ng\u00f6r\u00fclemeyen kesintilere yol a\u00e7abilir. Bu durumlar, genellikle Node.js s\u00fcre\u00e7 y\u00f6neticileri (PM2 gibi) taraf\u0131ndan yeniden ba\u015flat\u0131lsa bile, kullan\u0131c\u0131ya hizmet kesintisi olarak yans\u0131r.\n <\/p>\n\n\/\/ Asenkron Hatay\u0131 Yakalamay\u0131 Unutma Durumu\napp.get('\/data-api', async (req, res, next) => {\n \/\/ Burada try-catch veya .catch() yok!\n const data = await ThirdPartyService.fetchData(); \/\/ Diyelim ki bu bir hata f\u0131rlatt\u0131\n res.json(data);\n \/\/ Bu durumda hata, global \"unhandledRejection\" olay\u0131na d\u00fc\u015fer ve uygulamay\u0131 \u00e7\u00f6kertir.\n});\n <\/pre>\nTek K\u00fct\u00fcphane \u00c7\u00f6z\u00fcm\u00fc:
express-async-errors<\/code> ile Asenkron Hatalar\u0131 Nas\u0131l Y\u00f6netiriz?<\/h2>\ntry-catch<\/code> bloklar\u0131 veya .catch()<\/code> metotlar\u0131 ile y\u00f6netilmesi, yukar\u0131da bahsetti\u011fimiz gibi ciddi kod tekrar\u0131na ve bak\u0131m zorluklar\u0131na yol a\u00e7ar. \u0130\u015fte bu noktada, express-async-errors<\/code> k\u00fct\u00fcphanesi devreye girerek bu soruna zarif ve etkili bir \u00e7\u00f6z\u00fcm sunar. Bu k\u00fct\u00fcphane, Express.js'in asenkron i\u015flem i\u00e7indeki hatalar\u0131 otomatik olarak yakalamas\u0131n\u0131 ve bunlar\u0131 global hata i\u015fleyici middleware'inize iletmesini sa\u011flar. Adeta bir sihirli de\u011fnek gibi, t\u00fcm async\/await<\/code> veya Promise tabanl\u0131 rotalar\u0131n\u0131zdaki hatalar\u0131 manuel next(err)<\/code> \u00e7a\u011fr\u0131lar\u0131na gerek kalmadan yakalar.\n <\/p>\nexpress-async-errors<\/code> Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/strong>
\n Bu k\u00fct\u00fcphanenin \u00e7al\u0131\u015fma prensibi olduk\u00e7a zekicedir. express-async-errors<\/code>, Express.js'in temel Router.prototype.handle<\/code> ve Layer.prototype.handle<\/code> metotlar\u0131n\u0131 yama (patch) yaparak \u00e7al\u0131\u015f\u0131r. Bu sayede, bir rota i\u015fleyicisinden d\u00f6nen Promise reddedildi\u011finde (yani bir hata f\u0131rlat\u0131ld\u0131\u011f\u0131nda), bu hatay\u0131 otomatik olarak alg\u0131lar ve onu Express.js'in standart hata i\u015fleyici mekanizmas\u0131na (next(err)<\/code>) y\u00f6nlendirir. B\u00f6ylece, art\u0131k her asenkron rotan\u0131zda ayr\u0131 ayr\u0131 try-catch<\/code> bloklar\u0131 yazmak veya her .then().catch()<\/code> zincirini manuel olarak kurmak zorunda kalmazs\u0131n\u0131z. K\u00fct\u00fcphane, sizin yerinize bu i\u015flemi arka planda halleder. Bu sayede kodunuz \u00e7ok daha temiz, okunabilir ve s\u00fcrd\u00fcr\u00fclebilir hale gelir.\n <\/p>\n
\n express-async-errors<\/code> k\u00fct\u00fcphanesini kullanmak inan\u0131lmaz derecede basittir. \u00d6ncelikle, projenize npm veya yarn arac\u0131l\u0131\u011f\u0131yla kurman\u0131z gerekir:\n <\/p>\n\nnpm install express-async-errors\n# veya\nyarn add express-async-errors\n <\/pre>\napp.js<\/code> veya server.js<\/code>), Express uygulaman\u0131z\u0131 ba\u015flatmadan hemen \u00f6nce k\u00fct\u00fcphaneyi import etmektir. K\u00fct\u00fcphanenin kendisi hi\u00e7bir \u015feyi d\u0131\u015fa aktarmaz; sadece import edildi\u011fi anda Express.js'in \u00e7ekirdek metotlar\u0131n\u0131 yamalar.\n <\/p>\n\nrequire('express-async-errors'); \/\/ En ba\u015fta import edin!\nconst express = require('express');\nconst app = express();\n\n\/\/ Middleware'ler ve rotalar buraya gelecek\n\/\/ ...\n\n\/\/ \u015eimdi asenkron hatalar\u0131 manuel yakalamaya gerek yok!\napp.get('\/users\/:id', async (req, res) => {\n \/\/ \u00d6rne\u011fin, bir veritaban\u0131 i\u015flemi hata f\u0131rlatabilir\n const user = await someUserService.getUser(req.params.id);\n if (!user) {\n \/\/ next(new Error('Kullan\u0131c\u0131 bulunamad\u0131')) yerine do\u011frudan hata f\u0131rlatabiliriz\n throw new Error('UserNotFound');\n }\n res.json(user);\n});\n\napp.post('\/products', async (req, res) => {\n \/\/ Burada da bir hata f\u0131rlat\u0131labilir\n const newProduct = await someProductService.createProduct(req.body);\n res.status(201).json(newProduct);\n});\n\n\/\/ En sona global hata i\u015fleyici middleware'inizi ekleyin\napp.use((err, req, res, next) => {\n console.error('Yakalanan hata:', err.message);\n \/\/ Hata t\u00fcr\u00fcne g\u00f6re farkl\u0131 yan\u0131tlar d\u00f6nd\u00fcrebiliriz (ileriki b\u00f6l\u00fcmlerde ele al\u0131nacak)\n res.status(500).json({ message: 'Sunucu taraf\u0131nda beklenmeyen bir hata olu\u015ftu.' });\n});\n\napp.listen(3000, () => {\n console.log('Sunucu \u00e7al\u0131\u015f\u0131yor...');\n});\n <\/pre>\n\/users\/:id<\/code> ve \/products<\/code> rotalar\u0131ndaki async<\/code> fonksiyonlar i\u00e7indeki hatalar\u0131 manuel olarak try-catch<\/code> veya next(err)<\/code> ile sarmalamad\u0131\u011f\u0131m\u0131za dikkat edin. express-async-errors<\/code> k\u00fct\u00fcphanesi sayesinde, bu rotalarda f\u0131rlat\u0131lan herhangi bir hata otomatik olarak en sondaki app.use((err, req, res, next) => ...)<\/code> global hata i\u015fleyicisine ula\u015f\u0131r. Bu, kodunuzu inan\u0131lmaz derecede temizler ve asenkron hatalar\u0131 g\u00f6zden ka\u00e7\u0131rma riskini ortadan kald\u0131r\u0131r. Art\u0131k \"unhandled promise rejection\" endi\u015fesi olmadan async\/await<\/code>'in g\u00fcc\u00fcnden tam anlam\u0131yla faydalanabilirsiniz. Bu basit entegrasyon, Express.js hata y\u00f6netimindeki en b\u00fcy\u00fck zorluklardan birini tek bir sat\u0131r kodla \u00e7\u00f6zmenizi sa\u011flar.\n <\/p>\n
\n Uzman \u0130pucu: express-async-errors<\/code> k\u00fct\u00fcphanesini uygulaman\u0131z\u0131n entry point (giri\u015f) dosyas\u0131nda, di\u011fer t\u00fcm require<\/code> veya import<\/code> ifadelerinden ve Express uygulamas\u0131n\u0131 ba\u015flatmadan \u00f6nce \u00e7a\u011f\u0131rd\u0131\u011f\u0131n\u0131zdan emin olun. Bu, yaman\u0131n do\u011fru bir \u015fekilde uygulanmas\u0131n\u0131 sa\u011flar.
\n <\/span>\n <\/p>\nStandart Hata Yap\u0131s\u0131 Olu\u015fturma: \u00d6zel Hata S\u0131n\u0131flar\u0131 Kullanarak Ne Kazan\u0131r\u0131z?<\/h2>\n
express-async-errors<\/code> ile asenkron hatalar\u0131 yakalamay\u0131 otomatik hale getirdik. Ancak, yakalanan bu hatalar\u0131 nas\u0131l standart ve anlaml\u0131 bir \u015fekilde i\u015fleyece\u011fimiz hala \u00f6nemli bir konudur. Express.js'in varsay\u0131lan Error<\/code> nesnesi, genellikle sadece bir message<\/code> \u00f6zelli\u011fine sahiptir ve hata t\u00fcr\u00fc, HTTP durum kodu, ek detaylar gibi bilgileri i\u00e7ermez. Bu durum, istemci taraf\u0131 uygulamalar\u0131n hatalar\u0131 do\u011fru bir \u015fekilde yorumlamas\u0131n\u0131 zorla\u015ft\u0131r\u0131r ve sunucu taraf\u0131nda her hata t\u00fcr\u00fc i\u00e7in karma\u015f\u0131k if-else<\/code> yap\u0131lar\u0131 yazmam\u0131za neden olur. \u0130\u015fte bu noktada, \u00f6zel hata s\u0131n\u0131flar\u0131 devreye girer.\n <\/p>\n\n
instanceof<\/code> operat\u00f6r\u00fcn\u00fc kullanarak hata t\u00fcr\u00fcne g\u00f6re \u00f6zel i\u015flemler yapabilirsiniz.\n <\/li>\nerrorCode<\/code>, details<\/code>), hata ay\u0131klama s\u0131ras\u0131nda daha fazla bilgi sa\u011flar.\n <\/li>\n<\/ul>\nApiError<\/code> S\u0131n\u0131f\u0131 ile Tutarl\u0131 Hata Nesneleri Nas\u0131l Yarat\u0131l\u0131r?<\/h3>\nApiError<\/code> s\u0131n\u0131f\u0131 olu\u015ftural\u0131m. Bu s\u0131n\u0131f, t\u00fcm \u00f6zel hata s\u0131n\u0131flar\u0131m\u0131z\u0131n t\u00fcreyece\u011fi ve ortak \u00f6zellikleri (statusCode<\/code>, message<\/code>, isOperational<\/code>) i\u00e7erece\u011fi ana s\u0131n\u0131f olacakt\u0131r. isOperational<\/code> \u00f6zelli\u011fi, programlama hatalar\u0131 (\u00f6rne\u011fin, referans hatalar\u0131) ile uygulama hatalar\u0131n\u0131 (\u00f6rne\u011fin, kullan\u0131c\u0131 giri\u015fi do\u011frulama hatas\u0131) ay\u0131rt etmek i\u00e7in \u00f6nemlidir. Operasyonel hatalar genellikle bilinen ve beklenen hatalard\u0131r, programlama hatalar\u0131 ise beklenmedik durumlar\u0131 g\u00f6sterir.\n <\/p>\n\n\/\/ utils\/apiError.js\nclass ApiError extends Error {\n constructor(message, statusCode, isOperational = true, name = 'ApiError') {\n super(message);\n this.statusCode = statusCode;\n this.isOperational = isOperational; \/\/ Bilinen, beklenen hata m\u0131?\n this.name = name; \/\/ Hata s\u0131n\u0131f\u0131n\u0131n ad\u0131\n\n \/\/ Stack izini koru (V8 motoruna \u00f6zel)\n Error.captureStackTrace(this, this.constructor);\n }\n}\n\nmodule.exports = ApiError;\n <\/pre>\nApiError<\/code> s\u0131n\u0131f\u0131n\u0131 kullanarak, uygulamam\u0131zdaki belirli hata senaryolar\u0131 i\u00e7in \u00f6zel hata s\u0131n\u0131flar\u0131 olu\u015fturabiliriz:\n <\/p>\n\n\/\/ utils\/customErrors.js\nconst ApiError = require('.\/apiError');\n\nclass BadRequestError extends ApiError {\n constructor(message = 'Ge\u00e7ersiz \u0130stek', details = null) {\n super(message, 400, true, 'BadRequestError');\n this.details = details; \/\/ Ek do\u011frulama hata detaylar\u0131\n }\n}\n\nclass UnauthorizedError extends ApiError {\n constructor(message = 'Yetkilendirme Ba\u015far\u0131s\u0131z', details = null) {\n super(message, 401, true, 'UnauthorizedError');\n this.details = details;\n }\n}\n\nclass ForbiddenError extends ApiError {\n constructor(message = 'Bu \u0130\u015flemi Yapmaya Yetkiniz Yok', details = null) {\n super(message, 403, true, 'ForbiddenError');\n this.details = details;\n }\n}\n\nclass NotFoundError extends ApiError {\n constructor(message = 'Kaynak Bulunamad\u0131', details = null) {\n super(message, 404, true, 'NotFoundError');\n this.details = details;\n }\n}\n\nclass InternalServerError extends ApiError {\n constructor(message = 'Sunucu Taraf\u0131nda Beklenmeyen Hata', details = null) {\n super(message, 500, false, 'InternalServerError'); \/\/ 500 hatalar\u0131 genellikle operasyonel de\u011fil\n this.details = details;\n }\n}\n\nmodule.exports = {\n ApiError,\n BadRequestError,\n UnauthorizedError,\n ForbiddenError,\n NotFoundError,\n InternalServerError\n};\n <\/pre>\nthrow new BadRequestError('Ge\u00e7ersiz e-posta format\u0131')<\/code> veya throw new NotFoundError('Kullan\u0131c\u0131 bulunamad\u0131')<\/code> gibi ifadelerle anlaml\u0131 ve standartla\u015ft\u0131r\u0131lm\u0131\u015f hatalar f\u0131rlatabiliriz. Bu hata nesneleri, statusCode<\/code> gibi \u00f6nemli bilgileri kendi i\u00e7inde bar\u0131nd\u0131rd\u0131\u011f\u0131 i\u00e7in, global hata i\u015fleyicimiz bu bilgilere kolayca eri\u015febilir ve istemciye do\u011fru HTTP yan\u0131t\u0131n\u0131 g\u00f6nderebilir. Bu yakla\u015f\u0131m, sadece kodun okunabilirli\u011fini art\u0131rmakla kalmaz, ayn\u0131 zamanda uygulaman\u0131n hata y\u00f6netimini \u00e7ok daha \u00f6ng\u00f6r\u00fclebilir ve tutarl\u0131 hale getirir.\n <\/p>\nUygulamal\u0131 Ad\u0131mlar:
express-async-errors<\/code> ve \u00d6zel Hata S\u0131n\u0131flar\u0131n\u0131 Birlikte Kullanma<\/h2>\nexpress-async-errors<\/code> ile otomatik olarak yakalamay\u0131 ve \u00f6zel hata s\u0131n\u0131flar\u0131yla tutarl\u0131 hata yap\u0131lar\u0131 olu\u015fturmay\u0131 \u00f6\u011frendik. Bu b\u00f6l\u00fcmde, bu iki g\u00fc\u00e7l\u00fc arac\u0131 bir araya getirerek Express.js uygulamam\u0131zda kapsaml\u0131 ve standartla\u015ft\u0131r\u0131lm\u0131\u015f bir hata y\u00f6netim sistemi kurmay\u0131 ad\u0131m ad\u0131m inceleyece\u011fiz. Bu entegrasyon, uygulaman\u0131z\u0131n hata y\u00f6netimini hem verimli hem de bak\u0131m\u0131 kolay bir hale getirecektir.\n <\/p>\nGlobal Hata Y\u00f6netim Middleware'i Nas\u0131l Yaz\u0131l\u0131r?<\/h3>\n
express-async-errors<\/code> taraf\u0131ndan yakalanan ve \u00f6zel hata s\u0131n\u0131flar\u0131m\u0131zdan biri olan hatalar\u0131 do\u011fru \u015fekilde alg\u0131layacak ve istemciye uygun bir yan\u0131t g\u00f6nderecektir. Bu middleware, genellikle uygulaman\u0131z\u0131n en sonunda tan\u0131mlan\u0131r.\n <\/p>\n\n\/\/ middleware\/errorHandler.js\nconst { ApiError, InternalServerError } = require('..\/utils\/customErrors'); \/\/ \u00d6zel hata s\u0131n\u0131flar\u0131m\u0131z\n\nconst errorHandler = (err, req, res, next) => {\n \/\/ E\u011fer hata zaten bir ApiError ise, kendi durum kodunu ve mesaj\u0131n\u0131 kullan\n \/\/ De\u011filse, genel bir 500 hatas\u0131 olarak ele al\n let error = err;\n if (!(error instanceof ApiError)) {\n \/\/ Beklenmedik bir hata (programlama hatas\u0131) ise InternalServerError'a \u00e7evir\n \/\/ \u00dcretim ortam\u0131nda hassas bilgileri kullan\u0131c\u0131ya g\u00f6stermemek i\u00e7in\n error = new InternalServerError(\n process.env.NODE_ENV === 'production' ? 'Sunucu taraf\u0131nda beklenmeyen bir hata olu\u015ftu.' : err.message || 'Bilinmeyen Hata',\n err.stack \/\/ Geli\u015ftirme ortam\u0131nda stack izini g\u00f6ster\n );\n }\n\n \/\/ Konsola hata detaylar\u0131n\u0131 logla\n console.error([${error.name}] ${error.statusCode} - ${error.message}<\/code>);\n if (error.stack) {\n console.error(error.stack);\n }\n\n \/\/ Hata yan\u0131t\u0131n\u0131 olu\u015ftur\n res.status(error.statusCode || 500).json({\n success: false,\n message: error.message,\n ...(error.details && { details: error.details }), \/\/ E\u011fer varsa detaylar\u0131 ekle\n ...(process.env.NODE_ENV === 'development' && { stack: error.stack }) \/\/ Geli\u015ftirme ortam\u0131nda stack izi\n });\n};\n\nmodule.exports = errorHandler;\n <\/pre>\nerrorHandler<\/code> middleware'i, gelen hatan\u0131n ApiError<\/code> s\u0131n\u0131f\u0131n\u0131n bir \u00f6rne\u011fi olup olmad\u0131\u011f\u0131n\u0131 kontrol eder. E\u011fer \u00f6yleyse, hatan\u0131n kendi statusCode<\/code> ve message<\/code> de\u011ferlerini kullan\u0131r. Aksi takdirde (yani beklenmedik bir hata durumunda), bunu bir InternalServerError<\/code> olarak de\u011ferlendirir ve istemciye genel bir 500 hatas\u0131 d\u00f6nd\u00fcr\u00fcrken, hata detaylar\u0131n\u0131 yaln\u0131zca geli\u015ftirme ortam\u0131nda g\u00f6sterir. Bu, hem g\u00fcvenlik hem de kullan\u0131c\u0131 deneyimi a\u00e7\u0131s\u0131ndan en iyi pratiktir.\n <\/p>\nAPI U\u00e7 Noktalar\u0131nda Hata F\u0131rlatma ve Yakalama \u00d6rnekleri<\/h3>\n
app.js<\/code> dosyam\u0131zda t\u00fcm bu par\u00e7alar\u0131 bir araya getirelim.\n <\/p>\n\n\/\/ app.js veya server.js\n\nrequire('express-async-errors'); \/\/ express-async-errors'u en ba\u015fta dahil edin\nconst express = require('express');\nconst app = express();\nconst dotenv = require('dotenv');\ndotenv.config();\n\nconst { NotFoundError, BadRequestError, UnauthorizedError } = require('.\/utils\/customErrors');\nconst errorHandler = require('.\/middleware\/errorHandler');\n\n\/\/ JSON body parser middleware'i\napp.use(express.json());\n\n\/\/ \u00d6rnek Rota 1: Kullan\u0131c\u0131 Do\u011frulama\napp.post('\/api\/auth\/login', async (req, res) => {\n const { email, password } = req.body;\n\n if (!email || !password) {\n throw new BadRequestError('E-posta ve \u015fifre zorunludur.');\n }\n\n \/\/ Sim\u00fcle edilmi\u015f bir do\u011frulama i\u015flemi\n if (email === 'test@example.com' && password === 'password123') {\n res.json({ message: 'Ba\u015far\u0131yla giri\u015f yap\u0131ld\u0131.' });\n } else {\n throw new UnauthorizedError('Ge\u00e7ersiz kimlik bilgileri.');\n }\n});\n\n\/\/ \u00d6rnek Rota 2: Kaynak Bulunamad\u0131\napp.get('\/api\/products\/:id', async (req, res) => {\n const productId = req.params.id;\n \/\/ Sim\u00fcle edilmi\u015f bir veritaban\u0131 sorgusu\n const product = await new Promise(resolve => setTimeout(() => {\n if (productId === '123') {\n resolve({ id: '123', name: '\u00d6rnek \u00dcr\u00fcn', price: 99.99 });\n } else {\n resolve(null); \/\/ \u00dcr\u00fcn bulunamad\u0131\n }\n }, 50));\n\n if (!product) {\n throw new NotFoundError(ID'si ${productId} olan \u00fcr\u00fcn bulunamad\u0131.<\/code>);\n }\n res.json(product);\n});\n\n\/\/ \u00d6rnek Rota 3: Beklenmedik Hata (sim\u00fcle edilmi\u015f)\napp.get('\/api\/crash', async (req, res) => {\n \/\/ Burada k\u00fct\u00fcphanemizi kullanmadan bir hata f\u0131rlat\u0131yoruz,\n \/\/ express-async-errors ve global errorHandler bunu yakalayacak.\n const nonExistentVariable = undefined;\n nonExistentVariable.method(); \/\/ Bu bir TypeError f\u0131rlat\u0131r\n});\n\n\/\/ Mevcut olmayan rotalar i\u00e7in 404 hatas\u0131\napp.use((req, res, next) => {\n throw new NotFoundError('${req.originalUrl}' adresi bulunamad\u0131.<\/code>);\n});\n\n\/\/ Global hata i\u015fleyici middleware'imizi t\u00fcm rotalardan sonra ekliyoruz\napp.use(errorHandler);\n\nconst PORT = process.env.PORT || 3000;\napp.listen(PORT, () => {\n console.log(Sunucu ${PORT} portunda \u00e7al\u0131\u015f\u0131yor. Ortam: ${process.env.NODE_ENV}<\/code>);\n});\n <\/pre>\nexpress-async-errors<\/code> sayesinde rotalar\u0131m\u0131zda async<\/code> fonksiyonlar i\u00e7inde do\u011frudan \u00f6zel hata s\u0131n\u0131flar\u0131m\u0131zdan birini f\u0131rlatabiliyoruz (throw new BadRequestError(...)<\/code>). Bu hatalar, k\u00fct\u00fcphane taraf\u0131ndan otomatik olarak yakalan\u0131r ve en sondaki errorHandler<\/code> middleware'imize iletilir. errorHandler<\/code> da bu hatay\u0131 tan\u0131r, uygun HTTP durum kodunu ve mesaj\u0131 kullanarak istemciye standart bir JSON yan\u0131t\u0131 d\u00f6nd\u00fcr\u00fcr. Bu, hem kod tekrar\u0131n\u0131 \u00f6nler hem de hata y\u00f6netimini merkezi ve tutarl\u0131 hale getirir.\n <\/p>\ntry-catch<\/code> bloklar\u0131 yazmaya gerek kalmadan temiz ve okunabilir bir kodla \u00e7al\u0131\u015fabilirsiniz. Her t\u00fcrl\u00fc asenkron hata, ister kendiniz f\u0131rlat\u0131n isterse bir k\u00fct\u00fcphaneden gelsin, otomatik olarak yakalanacak ve tek bir yerden i\u015flenecektir. Bu yap\u0131, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k Express.js uygulamalar\u0131nda geli\u015ftirme h\u0131z\u0131n\u0131 ve uygulama kararl\u0131l\u0131\u011f\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r.\n <\/p>\nVaka Analizi: B\u00fcy\u00fck \u00d6l\u00e7ekli Bir Uygulamada Hata Y\u00f6netimi Nas\u0131l D\u00f6n\u00fc\u015ft\u00fcr\u00fcld\u00fc?<\/h2>\n
try-catch<\/code> bloklar\u0131 eksik b\u0131rak\u0131l\u0131yor, kimi zaman asenkron hatalar g\u00f6zden ka\u00e7\u0131yor ve uygulaman\u0131n beklenmedik anlarda \u00e7\u00f6kmesine neden oluyordu. En b\u00fcy\u00fck problem ise, istemcilere d\u00f6nen hata mesajlar\u0131n\u0131n ve HTTP durum kodlar\u0131n\u0131n son derece tutars\u0131z olmas\u0131yd\u0131.\n <\/p>\nProblemler ve Zorluklar:<\/h3>\n
\n
if-else<\/code> ve switch<\/code> blo\u011fu yaz\u0131lmas\u0131na neden oluyordu.\n <\/li>\n\u00c7\u00f6z\u00fcm ve Entegrasyon S\u00fcreci:<\/h3>\n
\n
express-async-errors<\/code> Entegrasyonu:<\/strong> \u0130lk ad\u0131m olarak, t\u00fcm projedeki asenkron hata yakalama sorununu \u00e7\u00f6zmek i\u00e7in express-async-errors<\/code> k\u00fct\u00fcphanesi uygulaman\u0131n en ba\u015f\u0131nda dahil edildi. Bu sayede, t\u00fcm async\/await<\/code> rotalar\u0131ndaki Promise reddetmeleri otomatik olarak global hata i\u015fleyiciye iletilmeye ba\u015fland\u0131. Bu basit ad\u0131m, uygulama \u00e7\u00f6kmelerini %80 oran\u0131nda azaltt\u0131.\n <\/li>\nBadRequestError<\/code>, UnauthorizedError<\/code>, NotFoundError<\/code>, InternalServerError<\/code>, vb.) i\u00e7in ApiError<\/code> s\u0131n\u0131f\u0131ndan t\u00fcreyen \u00f6zel hata s\u0131n\u0131flar\u0131 tan\u0131mland\u0131. Her s\u0131n\u0131f, kendi HTTP durum kodunu, kullan\u0131c\u0131ya g\u00f6sterilecek mesaj\u0131 ve geli\u015ftirme ortam\u0131nda ek detaylar\u0131 i\u00e7erecek \u015fekilde tasarland\u0131.\n <\/li>\nexpress-async-errors<\/code> taraf\u0131ndan yakalanan di\u011fer hatalar\u0131 i\u015fleyecek merkezi bir errorHandler<\/code> middleware'i geli\u015ftirildi. Bu middleware, hata t\u00fcr\u00fcne g\u00f6re dinamik HTTP durum kodlar\u0131 ve JSON yan\u0131tlar\u0131 d\u00f6nd\u00fcr\u00fcyordu. Ayr\u0131ca, \u00fcretim ortam\u0131nda hassas bilgilerin istemciye g\u00f6sterilmemesi ve sadece geli\u015ftirme ortam\u0131nda detayl\u0131 hata izlerinin sunulmas\u0131 sa\u011fland\u0131.\n <\/li>\ntry-catch<\/code> bloklar\u0131 yazmak yerine, geli\u015ftiriciler sadece hata durumunda ilgili \u00f6zel hatay\u0131 f\u0131rlat\u0131yorlard\u0131 (\u00f6rne\u011fin, throw new NotFoundError('\u00dcr\u00fcn bulunamad\u0131')<\/code>).\n <\/li>\n<\/ul>\nSonu\u00e7lar ve Kazan\u0131mlar:<\/h3>\n
\n
Geli\u015fmi\u015f Stratejiler ve \u0130pu\u00e7lar\u0131: Loglama ve \u0130zleme Entegrasyonu<\/h2>\n
Detayl\u0131 Loglama \u0130\u00e7in Winston veya Pino Entegrasyonu<\/h3>\n
console.error()<\/code> kullanmak basit uygulamalar i\u00e7in yeterli olabilir, ancak \u00fcretim ortam\u0131nda daha g\u00fc\u00e7l\u00fc bir loglama \u00e7\u00f6z\u00fcm\u00fcne ihtiyac\u0131n\u0131z vard\u0131r. Winston veya Pino gibi Node.js loglama k\u00fct\u00fcphaneleri, log seviyeleri (info, warn, error, debug), log dosyalar\u0131na veya harici hizmetlere (\u00f6rn: ELK Stack, Splunk) \u00e7\u0131kt\u0131 g\u00f6nderme, log formatlama ve performanstan \u00f6d\u00fcn vermeden loglama gibi \u00f6zellikler sunar.\n <\/p>\nerrorHandler<\/code> middleware'imizde Winston'\u0131 nas\u0131l kullanaca\u011f\u0131m\u0131za dair basit bir \u00f6rnek:\n <\/p>\n\n\/\/ utils\/logger.js\nconst winston = require('winston');\n\nconst logger = winston.createLogger({\n level: process.env.NODE_ENV === 'production' ? 'info' : 'debug',\n format: winston.format.combine(\n winston.format.timestamp({ format: 'YYYY-MM-DD HH:mm:ss' }),\n winston.format.json()\n ),\n transports: [\n new winston.transports.Console({\n format: winston.format.combine(\n winston.format.colorize(),\n winston.format.printf(info => [${info.timestamp}] ${info.level}: ${info.message}<\/code>)\n ),\n }),\n new winston.transports.File({ filename: 'error.log', level: 'error' }),\n new winston.transports.File({ filename: 'combined.log' }),\n ],\n exceptionHandlers: [\n new winston.transports.File({ filename: 'exceptions.log' })\n ],\n rejectionHandlers: [\n new winston.transports.File({ filename: 'rejections.log' })\n ],\n});\n\nmodule.exports = logger;\n <\/pre>\n<\/pre>\n
\n\/\/ middleware\/errorHandler.js (g\u00fcncellenmi\u015f)
\nconst { ApiError, InternalServerError } = require('..\/utils\/customErrors');
\nconst logger = require('..\/utils\/logger'); \/\/ Logger'\u0131 dahil et<\/p>\n
\n let error = err;
\n if (!(error instanceof ApiError)) {
\n error = new InternalServerError(
\n process.env.NODE_ENV === 'production' ? 'Sunucu taraf\u0131nda beklenmeyen bir hata olu\u015ftu.' : err.message || 'Bilinmeyen Hata',
\n err.stack
\n );
\n }<\/p>\n
\n logger.error({
\n message: [${error.name}] ${error.statusCode} - ${error.message}<\/code>,
\n stack: error.stack,
\n path: req.originalUrl,
\n method: req.method,
\n ip: req.ip,
\n userAgent: req.headers['user-agent']
\n });<\/p>\n
\n success: false,
\n message: error.message,
\n ...(error.details && { details: error.details }),
\n ...(process.env.NODE_ENV === 'development' && { stack: error.stack })
\n });
\n};<\/p>\n
\n <\/code><\/p>\nerrorHandler<\/code> i\u00e7inde entegre etmek, hatalar\u0131n \u00fcretim ortam\u0131nda an\u0131nda tespit edilmesini ve \u00e7\u00f6z\u00fcm\u00fcn\u00fc kolayla\u015ft\u0131r\u0131r. \u00d6rne\u011fin, Sentry entegrasyonu genellikle sadece Sentry.captureException(err);<\/code> eklemek kadar basittir.\n <\/p>\nMobil ve Duyarl\u0131 Hata Sayfalar\u0131 Tasar\u0131m\u0131<\/h3>\n
\n\n\n\n \n \n