Non-Fatal Error mobil tətbiqlərdə — mahiyyəti, növləri və xəta idarəetməsi

Non-Fatal Error nədir

Non-Fatal Error — prosesin dayandırılmasına səbəb olmayan istisna və ya xəta vəziyyətidir. Tətbiq işləməyə davam edir, lakin düzgün olmayan vəziyyətdə ola bilər: məlumatlar yüklənməyib, sorğu göndərilməyib, interfeys elementi göstərilməyib. İstifadəçi ya xətanı görmür, ya da mesaj görür və tətbiqdən istifadəni davam etdirir.

Əsas əlamətlər

Qeyri-fatal xəta həmişə proqrama bərpa yolu qoyur. Xəta idarəedicisi alternativ məlumatlar təklif edə, əməliyyatı təkrarlaya və ya interfeysin əvəzedicisini göstərə bilər. Əsas vəzifə crashın qarşısını almaq və istifadəçi təcrübəsini məqbul səviyyədə saxlamaqdır. Tərtibatçı hər catch blokunda açıq şəkildə bərpa ssenarisini nəzərdə tutmalıdır.

Tətbiqlərin sabitliyində rolu

Instabug 2024 məlumatına görə, istifadəçilərin 65%-i iki uğursuz qarşılıqlı əlaqədən sonra tətbiqi silir. Diqqətdən kənar qalan non-fatal xətalar yığılır və ümumi iş keyfiyyətini aşağı salır. Qeyri-fatal xətaların sistematik şəkildə loglanması və düzəldilməsi retentionu artırmaq və tətbiq mağazalarında istifadəçi reytinqlərini yaxşılaşdırmaq üçün birbaşa yoldur.

Qeyri-fatal xətaların növləri

Şəbəkə xətaları — mobil tətbiqlərdə ən geniş yayılmış non-fatal xəta növüdür. Bağlantı vaxtının aşılması, şəbəkənin itirilməsi, səhv server status kodu — bütün bu hallar crash olmadan tutulur və idarə olunur. İstifadəçiyə xidmətin əlçatan olmadığı barədə mesaj göstərilir və cəhdi təkrarlamaq təklif olunur. Şəbəkə xətaları üçün eksponensial gecikmə ilə retry nümunəsi xarakterikdir.

Məlumat validasiyası xətaları

Server cavabının səhv formatı, məcburi sahənin olmaması, səhv məlumat tipi — parsing xətaları tətbiq səhv məlumatları düzgün idarə edərsə, qeyri-fatal olur. Tipik yanaşma — standart ehtiyat dəyərlərdən istifadə və sonrakı server analizi üçün sorğu konteksti ilə parsing xətasının loglanmasıdır.

UI render xətaları

Şəkillərin yüklənməsi ilə bağlı problemlər, səhv şriftlər, layout xətaları — bunların heç biri fatal deyil, lakin istifadəçi təəssüratını pisləşdirir. Placeholder şəkillər və fallback dəyərlər boş ekranların qarşısını almağa və xətaları daha az nəzərə çarpdirmağa imkan verir. React Native-də UI xətaları üçün ehtiyat komponenti göstərən Error Boundary istifadə olunur.

Biznes məntiqi və vəziyyət xətaları

Hesablamalarda səhvlər, vəziyyət uyğunsuzluqları, ekranlar arasında səhv keçidlər — məntiqi xətalar çox vaxt crasha səbəb olmur, lakin tətbiqin səhv davranmasına gətirib çıxarır. Onları sistematik loglama və monitorinq olmadan aşkar etmək daha çətindir, çünki crash hesabatı yaratmır və istifadəçi şikayətinə qədər nəzərə çarpmır.

Non-Fatal Error vs Fatal Error: müqayisə

Non-Fatal Error fataldan onunla fərqlənir ki, proqrama işi davam etdirmək imkanı verir. Fatal error — tətbiqin bərpa edə bilmədiyi vəziyyətdir: null göstəricinin dereferensiyası, stack-in daşması, yaddaşın çatışmazlığı. Non-fatal xətanı tutmaq, idarə etmək və icranı davam etdirmək olar, fatal error isə tətbiqin yenidən başladılmasını tələb edir.

Non-fatal və fatal arasındakı sərhəd tətbiqdan asılı ola bilər. Şəbəkə vaxt aşımı bir tətbiqdə non-fatal kimi idarə olunur (sorğunun 1–2 saniyədən sonra təkrarlanması), digərində fatal ola bilər (idarəedici olmadıqda crash). Keyfiyyətli xəta idarəetməsi potensial fatal halları qeyri-fatala çevirir, tətbiqin sabitliyini artırır. Xəta idarəetmə sisteminin layihələndirilməsi yüksək etibarlılıq tələbləri olan mobil tətbiqin hazırlanmasında əsas memarlıq vəzifələrindən biridir. Quraşdırılmış monitorinq sistemi komandaya qeyri-fatal xətaları əhəmiyyətli sayda istifadəçiyə təsir etməzdən əvvəl tez aşkar etməyə və aradan qaldırmağa imkan verir.

Non-fatal xətaların loglanması

Firebase Crashlytics — mobil tətbiqlərdə qeyri-fatal xətaların loglanması üçün əsas vasitədir. recordException metodu tətbiqin işini kəsmədən tam stack trace və icra konteksti ilə non-fatal istisnanı qeydə almağa imkan verir. Crash hesabatlarından fərqli olaraq, recordException tutulan istisnaları loglamaq üçün kodun istənilən yerində çağırıla bilər.

fun fetchUserData(userId: String) {
    try {
        val response = apiService.getUser(userId)
        updateUI(response)
    } catch (e: IOException) {
        Crashlytics.log("Network error for user $userId")
        Crashlytics.recordException(e)
        showRetryDialog()
    } catch (e: JsonParseException) {
        // Non-fatal: ehtiyat məlumatlardan istifadə edirik
        Crashlytics.recordException(e)
        showFallbackContent()
    }
}

// İstifadəçi açarları ilə loglama
Crashlytics.setCustomKey("screen", "Profile")
Crashlytics.setCustomKey("api_version", "v3")

Sentry — daha ətraflı non-fatal xəta diaqnostikası ilə Crashlytics-ə alternativdir. Sentry SDK serverə istisna təfərrüatlarını göndərən captureException metodunu təqdim edir. Sentry-nin əsas üstünlüyü oxşar non-fatal xətaların bir issue-də qruplaşdırılması, təkrarlanma tezliyinin təhlili və breadcrumbs — xətadan əvvəl istifadəçi hərəkətlərinin ardıcıllığı şəklində icra kontekstidir.

Non-fatal xətaların loglanması meyarları

Bütün non-fatal xətaları loglamaq lazım deyil. Gözlənilən hallar — bağlantı olmadıqda şəbəkə çatışmazlığı — seçmə şəkildə loglana bilər. Gözlənilməz xətalar — idarə olunan koddakı NullPointerException, səhv məlumat formatı, logic error — həmişə loglanmalıdır. Hər komanda əhəmiyyət həddini özü müəyyən edir: gündə 1000 istifadəçiyə 10-dan 20-yə qədər unikal non-fatal xəta norma hesab olunur. Non-fatal xətaların sayının kəskin artmasına alertlər qurmaq vacibdir — bu, API-nin yeni versiyası ilə bağlı problemləri və ya buraxılışdan sonrakı reqressiyanı göstərə bilər.

Non-fatal xətaların kodda idarə olunması

Əsas idarəetmə mexanizmi — istisnanı tutan və bərpa kodunu icra edən try-catch-dir. Şəbəkə əməliyyatları üçün tipik nümunə — eksponensial gecikmə ilə sorğunun təkrarlanması (retry with backoff). Parsing xətaları üçün — standart ehtiyat dəyərlərdən istifadə və sonrakı server təhlili üçün kontekstin loglanması.

func loadImage(from url: URL) -> UIImage? {
    do {
        let data = try Data(contentsOf: url)
        return UIImage(data: data)
    } catch {
        Logger.shared.logError(error: "Image load failed: \(url)")
        return UIImage(named: "placeholder")
    }
}

func performRequest() async throws -> Data {
    var lastError: Error? = nil
    for attempt in 0..<3 {
        do {
            return try await URLSession.shared.data(from: url)
        } catch {
            lastError = error
            try await Task.sleep(UInt64(pow(2, attempt)) * 1_000_000_000)
        }
    }
    throw lastError ?? URLError(.unknown)
}

Result tipləri — istisnasız alternativ yanaşma. Funksiya Success və Failure variantları ilə sealed class Result qaytarır. Çağıran kod hər iki variantı açıq şəkildə idarə edir, bu da idarə olunmamış xətaları aradan qaldırır. Result tipləri tiplər səviyyəsində non-fatal halların açıq idarə edilməsi üçün Kotlin (standart kitabxanada Result) və Swift (Result) dillərində məşhurdur.

Non-fatal xətalar üçün fallback strategiyaları

Hər bir non-fatal xəta növü üçün bərpa strategiyası nəzərdə tutulmalıdır: şəbəkə xətası zamanı keşlənmiş məlumatların yüklənməsi, parsing xətası zamanı standart dəyərlərdən istifadə, UI xətası zamanı komponentin yenidən işə salınması. Yaxşı təcrübə — istifadəçiyə xəta barədə toast və ya snackbar göstərmək, lakin tətbiqlə qarşılıqlı əlaqəni tamamilə bloklamamaqdır. Bərpa olunan (recoverable) və bərpa olunmayan xətaları fərqləndirmək vacibdir — ikincilər üçün bərpa strategiyası fərqli olacaq, məsələn, ekranı yenidən başlatmaq və ya məlumatları təmizləmək təklifi. Əvvəlki uğurlu vəziyyətin keşlənməsi çox vaxt mobil platformalarda non-fatal xətaların idarə edilməsinin ən sadə və ən effektiv üsulu olur.