Mobil inkişafda xəta idarəetməsi: bu nədir, hansı texnikalar və necə təşkil etməli

iOS-da Xəta İdarəetməsi: Do-Catch, Throw, Guard Let

Xəta idarəetməsi Swift-də dörd əsas mexanizmə əsaslanır: do-catch, throws, guard let və if-let. Bir çox dillərdən fərqli olaraq, Swift tutulmayan istisnalara icazə vermir — hər bir xəta açıq şəkildə idarə edilməli və ya throws vasitəsilə bəyan edilməlidir. Xəta idarəetməsi mobil inkişaf üçün kritik bir bacarıqdır və birbaşa tətbiqin sabitliyinə təsir göstərir.

Do-Catch və Throw

do-catch throws ilə işarələnmiş funksiyaları çağırmaq üçün standart blokdur. do daxilində, try ilə bir funksiya çağırılır və o xəta atarsa, nəzarət catch-ə keçir. Müxtəlif xəta növləri pattern matching vasitəsilə idarə edilə bilər. Xəta idarə edilməzsə, o, yığında yuxarıya yayılır (Error Propagation). iOS-da effektiv xəta idarəetməsi üçün do-catch-i əsas mexanizm kimi istifadə edin.

Throw funksiya imzasında bəyan edilir: func fetchData() throws -> Data. Bu o deməkdir ki, çağıran kod xətanı try, try? və ya try! vasitəsilə idarə etməlidir. try? xətanı nil-ə çevirir, try! xəta zamanı çökməyə səbəb olur (yalnız uğura əmin olduqda istifadə edin). throw vasitəsilə xəta idarəetməsi Swift-də məcburi təcrübədir.

Optional/Nullable və Guard Let

Guard let dəyər nil olduqda funksiyadan erkən çıxmaq üçün bir konstruksiyadır. if-let-dən fərqli olaraq, guard let else şaxəsində çıxış (return, throw, break) tələb edir. Bu, kodu daha düz və oxunaqlı edir — iç-içə if blokları olmadan. Optional nil ola bilmirsə — force unwrap (!) istifadə edin, yalnız tam əmin olduqda. Mobil tətbiqdə guard let isteğe bağlı dəyərləri idarə edərkən çökmələrin qarşısını almağa kömək edir.

Optional Chaining (user?.address?.city) və nil-coalescing (??) açmadan optional ilə işləmək üçün sintaktik şəkərdir. IT Sectr-də biz API giriş parametrlərini yoxlamaq üçün guard let istifadə edirik və komandaya açıq şərh olmadan force unwrap-dan qaçmağı tələb edirik. Hər səviyyədə xəta idarəedicisi gözlənilməz nasazlıqlardan qoruyur.

Android-də Xəta İdarəetməsi: Try-Catch, Elvis, Sealed Class

Kotlin Android inkişafı üçün əsas dildir. O, Java-dan try-catch-i miras alır, lakin daha təhlükəsiz alternativlər əlavə edir: elvis operatoru, require, check və sealed class. Kotlin-də xəta idarəetməsi bu mexanizmlərin birləşməsinə əsaslanır. Swift-dən fərqli olaraq, Kotlin yoxlanılmış istisnaları idarə etməyi tələb etmir (bütün istisnalar yoxlanılmamışdır). Android-də mobil tətbiqlərdə xəta idarəetməsi üçün sealed class-ı əsas nümunə kimi istifadə edin.

Try-Catch və Elvis Operatoru

Try-catch Kotlin-də ifadə kimi işləyir — dəyər qaytarır. val result = try { fetchData() } catch (e: Exception) { fallbackValue }. Bu kodu qısaldır. Elvis operatoru (?:) nullable tiplər üçün nil-coalescing-in analoqudur: val name = user?.name ?: "Guest". Mobil tətbiqlərdə xəta idarəetməsi üçün ifadə kimi try-catch ən qısa yanaşmadır.

Sealed class uğur və xəta vəziyyətlərini modelləşdirmək üçün güclü bir vasitədir. sealed class NetworkResult { data class Success(val data: T) : NetworkResult(); data class Error(val message: String) : NetworkResult() }. when ifadəsində istifadə edildikdə, kompilyator şaxələrin tamlığını yoxlayır. sealed class vasitəsilə xəta idarəetməsi heç bir vəziyyətin idarə olunmamış qalmamasını təmin edir.

// Sealed class + try-catch — Android üçün tipik nümunə
sealed class NetworkResult<out T> {
    data class Success<out T>(val data: T) : NetworkResult<T>()
    data class Error(val message: String) : NetworkResult<Nothing>()
}

fun fetchUser(id: String): NetworkResult<User> {
    return try {
        NetworkResult.Success(api.getUser(id))
    } catch (e: Exception) {
        NetworkResult.Error("Failed: ${e.message}")
    }
}

Nümunədə, sealed class NetworkResult iki vəziyyəti modelləşdirir: məlumatla uğur və mesajla xəta. fetchUser funksiyası hər halda nəticə qaytarır və çağıran kod when vasitəsilə hər iki şaxəni idarə edir. Bu, idarə olunmamış xəta ehtimalını aradan qaldırır. sealed class vasitəsilə xəta idarəetməsi IT Sectr-də Android inkişafı üçün standartdır.

Kotlin-də Xəta İdarəetməsi: Result və Either

Result uğursuz ola biləcək bir əməliyyatın nəticəsini təmsil etmək üçün daxili Kotlin tipidir. O, fold, getOrThrow və ya map vasitəsilə uğur və uğursuzluğun idarə edilməsini məcbur edir. Result asinxron zəncirlərdə (coroutines) faydalıdır. Result ilə xəta idarəetməsi Kotlin-də mobil inkişaf üçün standartdır.

Result vs Either

Either Arrow kitabxanasından funksional bir tipdir və iki tipdən birinin dəyərini qaytarmağa imkan verir (Left — xəta, Right — uğur). Result-dan fərqli olaraq, Either istənilən istifadəçi tərəfindən təyin edilmiş xəta tipini ehtiva edə bilər. Sadə layihələr üçün daxili Result kifayətdir; mürəkkəb layihələr üçün Arrow-dan Either istifadə edin. Xəta idarəetmə alətinin seçimi layihənin mürəkkəbliyindən asılıdır.

Xəta Yayılması

Xəta yayılması xətanın idarə olunana qədər çağırış yığınında yuxarıya yayıldığı bir mexanizmdir. Kotlin-də bu, standart olaraq baş verir (yoxlanılmamış istisnalar). Swift-də bu, yalnız throws ilə işarələnmiş funksiyalara aiddir. Result və Either ilə xətalar yayılmır — onlar tipdə qalır və siz onları idarə etməlisiniz. Bu, mobil tətbiqlərdə xəta idarəetməsini daha təhlükəsiz edir.

Cədvəl əsas fərqləri göstərir. iOS açıq xəta bəyannaməsi (throws) tələb edir, bu da kodu daha təhlükəsiz, lakin daha ətraflı edir. Android tərtibatçı intizamına əsaslanır. IT Sectr-də biz Android üçün sealed class və iOS üçün throws istifadə edirik — bu, mobil tətbiqlərdə xəta idarəetməsi üçün hər iki platformanın ən yaxşı təcrübəsidir.

Çökmə Hesabatı: Crashlytics və Sentry

Çökmə hesabatı tətbiq çökmələrini toplamaq və təhlil etmək sistemidir. Çökmə hesabatı istehsalda xəta idarəetməsinin vacib hissəsidir. Onsuz, problemləri istifadəçilərdən öyrənirsiniz, bu isə istehsal üçün qəbuledilməzdir. İki əsas alət: Firebase Crashlytics (pulsuz) və Sentry (əsas istifadə üçün pulsuz). Mobil tətbiqlərdə xəta idarəetməsi üçün ilk buraxılışdan etibarən çökmə hesabatını tətbiq edin.

Firebase Crashlytics

Crashlytics Firebase-in bir hissəsidir. O, avtomatik olaraq çökmələri toplayır, çağırış yığınına görə qruplaşdırır və təsirlənmiş istifadəçilərin sayını göstərir. O, recordException() vasitəsilə ölümcül olmayan xətaların qeydiyyatını dəstəkləyir. İnteqrasiya: build.gradle (Android) və ya Podfile (iOS)-a SDK əlavə edin. Crashlytics layihəyə başlayarkən xəta idarəetməsi üçün ən yaxşı pulsuz alətdir.

Sentry

Sentry çarpaz platformalı xəta monitorinq sistemidir. Crashlytics-dən fərqli olaraq, Sentry ətraflı izləmə (breadcrumbs), performans monitorinqi və React Native dəstəyi təmin edir. Xəta anında tətbiqin vəziyyətini görməyə imkan verir. IT Sectr mobil inkişafda xəta idarəetməsi üzərində tam nəzarətə ehtiyacı olan layihələr üçün Sentry-i tövsiyə edir.

React Native-də Error Boundary

Error Boundary uşaq komponent ağacında JavaScript səhvlərini tutan və ehtiyat istifadəçi interfeysi göstərərək tətbiqin tam çökməsinin qarşısını alan React komponentidir. Error Boundary React Native-də xəta idarəetməsi üçün əsas komponentdir. Kritik ekranlar və naviqasiya üçün error boundaries istifadə edin. React Native-də mobil tətbiqlərdə xəta idarəetməsi yuxarı səviyyədə düzgün Error Boundary qurulmasını tələb edir.

Error Boundary Tətbiqi

Error Boundary componentDidCatch(error, errorInfo) və ya static getDerivedStateFromError(error) vasitəsilə yaradılır. O, asinxron koddakı (setTimeout, requestAnimationFrame), server tərəfli renderinqdəki və ya yerli səhvlərdəki (Native Modules) xətaları tutmur. Qeydiyyat üçün componentDidCatch daxilində çökmə hesabatı SDK-sından istifadə edin. Error Boundary UI təbəqəsi üçün sadə, lakin effektiv xəta idarəedicisidir.

Ölümcül və Qeyri-Ölümcül Xətalar

Ölümcül xəta tətbiqin çökməsinə səbəb olan idarə olunmamış istisnadır. Qeyri-ölümcül xəta tutduğunuz və idarə etdiyiniz, lakin kodda bir problemi göstərən istisnadır. Qeyri-ölümcül xətalar Crashlytics/Sentry vasitəsilə qeydə alınır və ölümcül olmamışdan əvvəl səhvləri tapmağa kömək edir. Həm ölümcül, həm də qeyri-ölümcül xətalar mobil inkişafda düzgün xəta idarəetməsi tələb edir.