1. 404 yanıtı neden catch içine düşmeyebilir?

Bir API'den ürün listesi aldığını düşün. İstek sunucuya ulaştı, fakat uç nokta 404 döndürdü. fetch çağrısı bu durumda bir Response nesnesi verebilir; yalnızca catch bloğuna güvenen kod, yanıtı başarılı sanarak JSON okumaya devam eder. Ardından gelen ayrıştırma hatası da gerçek problemin üstünü örter.

İlk kontrol response.ok olmalıdır. Bu değer 200–299 aralığını ifade eder. Uygulaman için her 2xx yanıtın aynı anlama geldiğini varsayma: örneğin 204 yanıtının gövdesi boş olabilir. Beklediğin sözleşmeyi ayrıca tanımla; durum kodu, içerik türü ve veri şekli farklı kontrol katmanlarıdır.

2. Sınırlı bekleme ve açık hata mesajı

Aşağıdaki örnek yalnızca aynı kaynaktaki bir GET isteği içindir. Zamanlayıcı isteği iptal eder; finally bloğu da sonuç ne olursa olsun zamanlayıcıyı temizler. Başarısız HTTP yanıtını JSON hatasından ayıran mesaj üretmek, hata ayıklarken hangi aşamada sorun olduğunu anlamanı sağlar.

Bu yardımcı tüm bir ağ kütüphanesinin yerine geçmez. Dosya indirme, boş gövde, akış veya kimlik doğrulama isteyen servislerde sözleşme değişir. Örneği ihtiyaca göre genişletirken varsayılan yeniden deneme ekleme; yazma isteğinin yinelenmesi ikinci bir işlem yaratabilir.

JavaScript
async function readJson(path, timeoutMs = 8000) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), timeoutMs);
  try {
    const response = await fetch(path, { signal: controller.signal });
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    if (response.status === 204) return null;
    const type = response.headers.get('content-type') || '';
    if (!type.includes('application/json')) {
      throw new Error('JSON yanıtı bekleniyordu');
    }
    return await response.json();
  } finally {
    clearTimeout(timer);
  }
}

3. Veri şekli ayrı bir sözleşmedir

Geçerli JSON her zaman beklediğin veri değildir. Sunucu bir dizi yerine hata nesnesi döndürebilir veya items alanını kaldırmış olabilir. Arayüze aktarmadan önce temel şekli kontrol et: bir liste bekliyorsan Array.isArray kullan, zorunlu alanlar için açık doğrulama yap. Büyük projelerde bir şema doğrulayıcı bu sınırı merkezileştirebilir.

Kullanıcıya sunucunun bütün hata metnini gösterme. Bu metin iç sistem adları veya teknik ayrıntı içerebilir. Arayüzde anlaşılır bir mesaj, günlükte ise hassas değerleri çıkarılmış teknik bağlam kullan. “Şu anda yüklenemedi, tekrar dene” mesajı kullanıcı için çoğu zaman yığın izinden daha kullanışlıdır.

4. Tekrar deneme ve yarış koşulları

Arama kutusunda her tuş vuruşu yeni bir istek başlatıyorsa önceki yanıt sonradan gelip yeni sonucu ezebilir. Yeni istek başladığında önceki controller üzerinden iptal etmek veya istek sıra numarasıyla eski yanıtı yok saymak bu yarışı yönetir. Yalnızca yükleniyor göstergesini eklemek sorunu çözmez.

Geçici servis kesintilerinde tekrar deneme mantıklı olabilir; ancak sınırlı deneme sayısı ve bekleme gerekir. 401 gibi oturum problemlerinde kör tekrar yerine oturum akışını ele al. 429 durumunda servis Retry-After veriyorsa bu süreyi dikkate al. POST isteğini tekrar göndermeden önce sunucunun idempotency sözleşmesini öğren.

5. Bu örneği nasıl doğrularsın?

Başarılı JSON, 404, 204, bozuk JSON ve yanıt vermeyen servis için ayrı kontroller yap. İptal durumunda AbortError oluşacağını ele al; kullanıcı özellikle başka sayfaya geçtiyse bunu görünür hata olarak sunman gerekmeyebilir. Ağ panelinde bir isteğin gerçekten iptal edildiğini ve yeniden denemelerin sınırsız olmadığını gözle.

CORS hatasını tarayıcı güvenliğini kapatarak çözme. Sunucu hangi kökenlere erişim vereceğini doğru belirlemelidir. İstemcide no-cors seçmek, yanıtı normal bir JSON nesnesi gibi okuyabilmeni sağlamaz. Hata yönetimi, güvenlik mekanizmasını atlatma yöntemi değildir.

Kaynaklar ve kontrol notu

Bu rehber yapay zekâ desteğiyle hazırlanmış özgün bir editoryal içeriktir. Kaynak kontrolü: 30 Eylül 2026. Örnekleri kendi proje koşullarına uyarlayarak doğrula.

Bir hata fark ettiysen editörlüğe bildir; düzeltmeleri güncelleme tarihiyle işleriz.