🧱 D4 · Exception Filter ve HttpException

D4 · Exception Filter ve HttpException: Nest'in Exception Filter'ı, Spring'in `@RestControllerAdvice`'inin **decorator ile işaretlenmiş TAM karşılığıdır**: Spring'de `@ExceptionH

Nest'in Exception Filter'ı, Spring'in `@RestControllerAdvice`'inin **decorator ile işaretlenmiş TAM karşılığıdır**: Spring'de `@ExceptionHandler(NotFoundException.class)` bir metoda "bu exception tipini SEN yakala" der; Nest'te `@Catch(HttpException)` bir sınıfa AYNI şeyi söyler — hangi hata TİPİNİN bu filtreye düşeceği decorator'da AÇIKÇA yazılıdır (Express'teki C5'in aksine, burada parametre SAYISI değil, decorator TİPİ belirleyicidir). `HttpException` (ve `NotFoundException`, `BadRequestException` gibi alt sınıfları) Nest'in kendi hazır hata sınıflarıdır — `throw new NotFoundException('Bug bulunamadi')` yazman, Spring'de özel bir exception sınıfı fırlatmana denktir. Peki Nest'in kendi VARSAYILAN exception davranışı zaten JSON döndürüyorken (Express'in HTML'ine kıyasla bir adım öndedir), neden hâlâ özel bir filter yazıyoruz? Çünkü tester'ın beklediği hata gövdesinin ŞEKLİ (`{ error: "..." }` mi, `{ message: "...", statusCode: ... }` mi) projenin SÖZLEŞMESİNE göre değişir — varsayılan davranış "bir şey" döner ama SÖZLEŞMEYE UYAN şeyi döndürmesi GARANTİ değildir; bu garantiyi filter'ı hem yazıp hem KAYDETMEK verir.

Özel Filter Yazmak ve Global Kaydetmek

Micro Lab: Kod yazma

TODO satirini beklenen cozumdeki kritik satirla degistir. Bu gercek runtime degil; amac dogru yapinin yazilmasini kontrollu olarak pekistirmek.

Adim Adim: Kod yazma

Amaci ve girdiyi belirle

Kritik satiri tamamla

Cikti veya davranisi kontrol et

Hata mesajini kanit olarak oku

Duzeltmeyi tekrar calistir

Kod okuma ve dogrulama akisini sirala.

**🐞 Defect Doğum Anı — `app.useGlobalFilters(...)` unutulursa** **Kod:** `HttpExceptionFilter` sınıfı `@Catch(HttpException)` ile KUSURSUZ yazıldı, `{ error: exception.message }` sözleşmeye tam uyuyor — ama `main.ts`'te `app.useGlobalFilters(new HttpExceptionFilter())` çağrısı YOK. **Ne olur:** `GET /api/v1/bugs/999` request'i için `throw new NotFoundException(...)` çalışır, ama özel filter kayıtlı olmadığı için Nest kendi VARSAYILAN hata işleyicisine düşer — bu da JSON döner ama proje sözleşmesindeki `{ error: "..." }` yerine Nest'in kendi şekli olan `{ statusCode: 404, message: "...", error: "Not Found" }`'u döndürür. **Neden sinsi:** Request yine JSON döner (Express'teki HTML sürprizinden farklı olarak SUNUCU tarafında "çökmüş" görünmez), hatta 404 status kodu da doğrudur — ama gövdenin ŞEKLİ projenin beklediğinden farklıdır. Bir tester sadece status kodunu kontrol ediyorsa bu farkı HİÇ fark etmez. **Tester nerede yakalar:** Hata gövdesinin TAM ŞEKLİNİ (`error` alanının varlığını, `statusCode`/`message` gibi fazladan alanların olup olmadığını) doğrulayan bir assertion yazınca — sadece "404 mü?" diye sormak yetersizdir, "gövde SÖZLEŞMEYE uyuyor mu?" sorusu şarttır.

🎬 Doğru Filter, Kayıtsız — Yanlış Şekilli JSON

throw new NotFoundException()