Fatal Error: چیست، علل اصلی و روش‌های پیشگیری

Fatal Error چیست

Fatal Error — خطایی است که ادامه اجرای برنامه غیرممکن می‌شود. سیستم‌عامل یا ماشین مجازی فرآیند را خاتمه می‌دهد تا از تخریب داده‌ها جلوگیری کند. در iOS خطای بحرانی باعث سیگنال SIGABRT یا SIGSEGV می‌شود، در Android — یک استثنای مدیریت‌نشده که به handler ریشه می‌رسد و فرآیند را خاتمه می‌دهد. برنامه فوراً بسته می‌شود و کاربر به صفحه اصلی بازمی‌گردد.

علائم خطای بحرانی

علائم مشخصه خطای بحرانی: گزارش crash با stack trace کامل، ناپدید شدن غیرمنتظره برنامه، ثبت خاتمه فرآیند در log سیستم، صفحه سیاه یا سفید قبل از بسته شدن. کاربر صفحه اصلی را بدون امکان بازیابی جلسه می‌بیند — برنامه باید از حالت صفر راه‌اندازی مجدد شود. در iOS crash با نوشته شدن در فایل .crash قابل دسترسی از طریق Xcode Organizer همراه است.

تأثیر بر معیارهای کسب‌وکار

هر crash بر نگهداشت کاربر تأثیر منفی دارد. طبق Google Play Console 2024، برنامه‌هایی با crash-free rate کمتر از 99.5% رتبه پایین‌تری در جستجو و توصیه‌ها دریافت می‌کنند. Crash-rate یکی از سیگنال‌های کلیدی کیفیت برای App Store و Google Play است — سطح بالای خطاهای بحرانی می‌تواند انتشار به‌روزرسانی‌ها را مسدود کند. برای برنامه‌های مالی و پزشکی crash-free rate کمتر از 99.9% غیرقابل قبول تلقی می‌شود.

علل خطاهای بحرانی

Null-pointer dereference — علت اصلی خطاهای بحرانی در برنامه‌های موبایل. تلاش برای دسترسی به ویژگی یا متد یک شیء که برابر null است باعث NullPointerException در Android یا EXC_BAD_ACCESS در iOS می‌شود. طبق JetBrains 2023، حدود 28% از تمام crash-های تولیدی مربوط به null-pointerها است. در Kotlin سیستم null-safety این درصد را به‌طور قابل توجهی کاهش می‌دهد، اما force unwrap و سازگاری با Java منابع مشکل باقی می‌مانند.

Index-out-of-bounds

دسترسی به عنصر مجموعه با اندیس ناموجود — دومین علت رایج crash-ها. در Java و Kotlin این ArrayIndexOutOfBoundsException است، در Swift — fatal error: Index out of range. اغلب هنگام کار با لیست‌ها پس از فیلتر کردن یا تغییر اندازه پویای مجموعه رخ می‌دهد. استفاده از روش‌های ایمن getOrNull (Kotlin) یا indices.contains (Swift) از این نوع خطاهای بحرانی جلوگیری می‌کند.

Crash-های مرتبط با منابع

کمبود حافظه (OutOfMemoryError)، سرریز پشته (StackOverflowError)، بارگذاری منبع ناموجود — خطاهای منبع اغلب بحرانی و دشوار برای بازتولید هستند. OutOfMemoryError هنگام بارگذاری تصاویر بزرگ بدون فشرده‌سازی یا نشت حافظه به دلیل ارجاع‌های آزادنشده رخ می‌دهد. StackOverflowError — در بازگشت عمیق بدون حالت پایه یا فراخوانی‌های چرخه‌ای در زنجیره delegateها.

خطاهای هم‌روندی

Deadlock، race condition، تغییر مجموعه در حین تکرار — خطاهای چندنخی به‌صورت غیرقطعی ظاهر می‌شوند و سخت‌ترین آن‌ها برای تشخیص هستند. در Android ConcurrentModificationException هنگام تغییر ArrayList از نخ‌های مختلف، در iOS crash به دلیل تغییر NSMutableArray بدون همگام‌سازی. استفاده از کوروتین‌های Kotlin (structured concurrency) یا Swift Actors (iOS 16+) احتمال crash-های هم‌روندی را کاهش می‌دهد.

Fatal Error در مقابل Non-Fatal Error

تفاوت کلیدی — امکان بازیابی. Non-Fatal Error به برنامه اجازه ادامه کار می‌دهد: timeout شبکه با try-catch مدیریت می‌شود، خطای تجزیه با مقدار پیش‌فرض جایگزین می‌شود. Fatal Error چنین راهی ندارد — crash اجتناب‌ناپذیر است و برنامه باید مجدداً راه‌اندازی شود. مرز بین این نوع خطاها توسط معماری برنامه تعیین می‌شود.

یک خطا ممکن است در یک پلتفرم fatal و در دیگری non-fatal باشد. تقسیم بر صفر در Java/Kotlin ArithmeticException پرتاب می‌کند (بحرانی نیست — قابل catch)، در Swift باعث fatal error: Division by zero (crash بدون امکان catch) می‌شود. توسعه‌دهنده باید رفتار زبان خاص و محیط runtime را در طراحی مدیریت خطا در نظر بگیرد. درک مرز بین fatal و non-fatal — اساس ساخت معماری مقاوم به خطای برنامه موبایل است.

تشخیص خطاهای بحرانی

Firebase Crashlytics — استاندارد دوفاکتو برای تشخیص crash-ها در برنامه‌های موبایل. SDK به‌طور خودکار stack trace، وضعیت دستگاه، نسخه سیستم‌عامل و logهای درست قبل از crash را جمع‌آوری می‌کند. Dashboard crashهای مشابه را در یک issue گروه‌بندی می‌کند و تعداد کاربران تحت تأثیر، فراوانی تکرار و نسخه برنامه‌ای که crash در آن رخ داده را نشان می‌دهد.

// مقداردهی اولیه Crashlytics در برنامه Android
class MainApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseApp.initializeApp(this)
        Crashlytics.setCustomKey("build_type", "production")
    }
}

// تنظیم داده‌های سفارشی برای تشخیص crash
Crashlytics.setUserId("user_12345")
Crashlytics.setCustomKey("screen", "ProfileFragment")
Crashlytics.setCustomKey("api_response", responseCode)

// Crash اجباری برای تست ادغام
Crashlytics.crash()

Sentry — جایگزینی با تشخیص دقیق‌تر. Sentry نه تنها stack trace، بلکه وضعیت همه متغیرها، توالی رویدادها تا خطا و زمینه اجرا را نشان می‌دهد. Breadcrumbs Sentry امکان بازسازی زنجیره اقدامات کاربر قبل از خطای بحرانی را فراهم می‌کند: کلیک دکمه‌ها، جابجایی بین صفحه‌ها، درخواست‌های شبکه. در Sentry نظارت بر عملکرد و جلسات برای تحلیل جامع کیفیت در دسترس است.

Symbolication و deobfuscation

برای تشخیص صحیح crash-ها در iOS نیاز به بارگذاری فایل‌های dSYM (debug symbols) در Crashlytics یا Sentry است. بدون dSYM stack trace فقط شامل آدرس‌های حافظه به جای نام توابع خواهد بود. برای Android بارگذاری فایل‌های mapping هنگام استفاده از ProGuard یا R8 الزامی است. خودکارسازی بارگذاری dSYM از طریق build phase در Xcode یا پلاگین Gradle برای ساخت‌های تولیدی اجباری است.

پیشگیری از خطاهای بحرانی

روش پایه پیشگیری — safe unwrapping همه مقادیر optional و nullable. استفاده از if-let در Swift و let با ?: در Kotlin خطاهای null-pointer را حذف می‌کند. هیچ force unwrap بدون تضمین وجود مقدار. کامپایلرهای Kotlin و Swift هر دو در مورد عملیات‌های بالقوه خطرناک هشدار می‌دهند — این هشدارها را نمی‌توان در کد تولیدی نادیده گرفت.

// پیشگیری از fatal error از طریق safe unwrapping
func processUser(id: String) -> String {
    guard let user = database.findUser(by: id) else {
        return "User not found"
    }
    guard let email = user.email else {
        return "Email not set"
    }
    return email
}

// دسترسی ایمن به عناصر مجموعه
func safeGet <T>(items: [T], index: Int) -> T? {
    guard items.indices.contains(index) else { return nil }
    return items[index]
}

// بررسی مرزهای آرایه قبل از دسترسی
let numbers = [1, 2, 3]
if numbers.indices.contains(5) {
    print(numbers[5])
} else {
    print("Index out of range")
}

Defensive programming — سطح دوم محافظت. همیشه پارامترهای ورودی توابع را بررسی کنید، به جای force unwrap Optional یا Result برگردانید، از assert در ساخت‌های debug برای تشخیص زودهنگام خطاها استفاده کنید. تست‌های واحد برای موارد مرزی (null، مجموعه‌های خالی، اندیس‌های نامعتبر) باید تمام نقاط ورود عمومی منطق کسب‌وکار برنامه را پوشش دهند.

Error Boundary برای لایه UI

در React Native و SwiftUI می‌توان error boundary تنظیم کرد — مؤلفه‌ای که خطاهای بحرانی رندر را می‌گیرد و به جای crash یک UI جایگزین نشان می‌دهد. این کار خطای بحرانی UI را از دید کاربر به non-fatal تبدیل می‌کند — برنامه به کار خود ادامه می‌دهد و کاربر به جای صفحه سفید، پیام خطا را در یک بلوک خاص از رابط می‌بیند.

بررسی‌های crash در CI/CD

ادغام بررسی‌های خودکار در pipeline CI/CD: تحلیل ایستا (Detekt برای Kotlin، SwiftLint برای Swift)، اجرای تست‌های UI روی دستگاه‌های واقعی، بررسی crash-free rate در محیط تست. مسدودسازی merge هنگام تجاوز از آستانه crash-rate (آستانه توصیه‌شده — بیش از 0.1% crash جدید در هر commit).