موبائل ایپس میں Non-Fatal Error — جوہر، اقسام اور ایرر ہینڈلنگ

Non-Fatal Error کیا ہے

Non-Fatal Error — ایک استثناء یا غلطی کی حالت ہے جو عمل کے خاتمے کا سبب نہیں بنتی۔ ایپلیکیشن کام کرتی رہتی ہے، لیکن غلط حالت میں ہو سکتی ہے: ڈیٹا لوڈ نہیں ہوا، درخواست نہیں بھیجی گئی، انٹرفیس عنصر ظاہر نہیں ہوا۔ صارف یا تو غلطی کو محسوس نہیں کرتا، یا پیغام دیکھتا ہے اور ایپلیکیشن استعمال کرتا رہتا ہے۔

اہم خصوصیات

غیر مہلک غلطی ہمیشہ پروگرام کو بحالی کا راستہ چھوڑتی ہے۔ ایرر ہینڈلر متبادل ڈیٹا فراہم کر سکتا ہے، آپریشن دوبارہ کر سکتا ہے، یا انٹرفیس پلیس ہولڈر دکھا سکتا ہے۔ بنیادی مقصد کریش کو روکنا اور قابل قبول صارف تجربہ برقرار رکھنا ہے۔ ڈویلپر کو ہر catch بلاک میں واضح طور پر بحالی کے منظر نامے کی منصوبہ بندی کرنی چاہیے۔

ایپلیکیشن استحکام میں کردار

Instabug 2024 کے مطابق، 65% صارفین دو ناکام تعاملات کے بعد ایپ ان انسٹال کر دیتے ہیں۔ غیر مہلک غلطیاں جن پر توجہ نہ دی جائے جمع ہوتی ہیں اور مجموعی معیار کو کم کرتی ہیں۔ غیر مہلک غلطیوں کی منظم لاگنگ اور اصلاح صارف کی برقراری کو بہتر بنانے اور ایپ اسٹور کی درجہ بندی بڑھانے کا براہ راست راستہ ہے۔

غیر مہلک غلطیوں کی اقسام

نیٹ ورک کی غلطیاں موبائل ایپلیکیشنز میں غیر مہلک غلطیوں کی سب سے عام قسم ہیں۔ کنکشن ٹائم آؤٹ، نیٹ ورک کی کمی، غلط سرور اسٹیٹس کوڈ — یہ تمام صورتیں بغیر کریش کے پکڑی اور ہینڈل کی جاتی ہیں۔ صارف کو دوبارہ کوشش کے آپشن کے ساتھ سروس کی عدم دستیابی کا پیغام دکھایا جاتا ہے۔ ایکسپونیشنل بیک آف کے ساتھ دوبارہ کوشش کا پیٹرن نیٹ ورک کی غلطیوں کے لیے عام ہے۔

ڈیٹا کی توثیق کی غلطیاں

غلط سرور رسپانس فارمیٹ، لازمی فیلڈ کی کمی، غلط ڈیٹا کی قسم — پارسنگ کی غلطیاں غیر مہلک ہوتی ہیں اگر ایپلیکیشن غلط ڈیٹا کو صحیح طریقے سے ہینڈل کرے۔ عام طریقہ ڈیفالٹ فال بیک ویلیوز استعمال کرنا اور بعد میں سرور سائڈ تجزیہ کے لیے درخواست کے سیاق و سباق کے ساتھ پارسنگ کی غلطی کو لاگ کرنا ہے۔

UI رینڈرنگ کی غلطیاں

تصویر لوڈ کرنے کے مسائل، غلط فونٹس، لے آؤٹ کی غلطیاں — یہ سب غیر مہلک ہیں لیکن صارف کے تجربے کو خراب کرتی ہیں۔ پلیس ہولڈر تصاویر اور فال بیک ویلیوز خالی اسکرینوں سے بچنے اور غلطیوں کو کم نمایاں کرنے میں مدد کرتی ہیں۔ React Native میں، UI غلطیوں کے لیے فال بیک کمپوننٹ دکھانے والا Error Boundary استعمال ہوتا ہے۔

کاروباری منطق اور حالت کی غلطیاں

حساب کی غلطیاں، حالت کا عدم مطابقت، غلط اسکرین ٹرانزیشن — منطقی غلطیاں اکثر کریش کا سبب نہیں بنتیں لیکن ایپلیکیشن کے غلط رویے کا باعث بنتی ہیں۔ منظم لاگنگ اور مانیٹرنگ کے بغیر ان کا پتہ لگانا مشکل ہے کیونکہ وہ کریش رپورٹ نہیں بناتیں اور صارف کی شکایت تک بے خبر رہتی ہیں۔

Non-Fatal Error vs Fatal Error: موازنہ

Non-Fatal Error مہلک سے اس لحاظ سے مختلف ہے کہ یہ پروگرام کو کام جاری رکھنے کا موقع چھوڑتا ہے۔ مہلک غلطی ایک ایسی حالت ہے جس سے ایپلیکیشن بحال نہیں ہو سکتی: null پوائنٹر ڈیریفرنس، اسٹیک اوور فلو، میموری ختم۔ غیر مہلک غلطی کو پکڑا، ہینڈل کیا جا سکتا ہے اور عمل جاری رکھا جا سکتا ہے، جبکہ مہلک غلطی کے لیے ایپلیکیشن کو دوبارہ شروع کرنے کی ضرورت ہوتی ہے۔

غیر مہلک اور مہلک کے درمیان حد عملدرآمد پر منحصر ہو سکتی ہے۔ ایک ایپلیکیشن میں نیٹ ورک ٹائم آؤٹ کو غیر مہلک سمجھ کر ہینڈل کیا جاتا ہے (1–2 سیکنڈ بعد دوبارہ کوشش)، جبکہ دوسری میں یہ مہلک ہو سکتا ہے (اگر کوئی ہینڈلر نہ ہو تو کریش)۔ معیاری ایرر ہینڈلنگ ممکنہ طور پر مہلک صورتحال کو غیر مہلک میں بدل دیتی ہے، ایپلیکیشن کے استحکام کو بڑھاتی ہے۔ ایک موبائل ایپلیکیشن کو اعلیٰ اعتماد کے تقاضوں کے ساتھ تیار کرتے وقت ایرر ہینڈلنگ سسٹم ڈیزائن کرنا اہم آرکیٹیکچرل کاموں میں سے ایک ہے۔ ایک بلٹ ان مانیٹرنگ سسٹم ٹیم کو غیر مہلک غلطیوں کو بڑی تعداد میں صارفین کو متاثر کرنے سے پہلے جلدی سے پکڑنے اور درست کرنے کی اجازت دیتا ہے۔

غیر مہلک غلطیوں کی لاگنگ

Firebase Crashlytics موبائل ایپلیکیشنز میں غیر مہلک غلطیوں کو لاگ کرنے کا بنیادی ٹول ہے۔ recordException طریقہ ایپلیکیشن میں خلل ڈالے بغیر مکمل اسٹیک ٹریس اور عملدرآمد کے سیاق و سباق کے ساتھ ایک غیر مہلک استثناء کو کیپچر کرنے کی اجازت دیتا ہے۔ کریش رپورٹس کے برعکس، پکڑے گئے استثناء کو لاگ کرنے کے لیے کوڈ میں کہیں بھی recordException کو کال کیا جا سکتا ہے۔

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: فال بیک ڈیٹا استعمال کریں
        Crashlytics.recordException(e)
        showFallbackContent()
    }
}

// کسٹم کیز کے ساتھ لاگنگ
Crashlytics.setCustomKey("screen", "Profile")
Crashlytics.setCustomKey("api_version", "v3")

Sentry غیر مہلک غلطیوں کے لیے مزید تفصیلی تشخیص کے ساتھ Crashlytics کا متبادل ہے۔ Sentry SDK captureException طریقہ فراہم کرتا ہے، جو سرور کو استثناء کی تفصیلات بھیجتا ہے۔ Sentry کا اہم فائدہ اسی طرح کی غیر مہلک غلطیوں کو ایک مسئلے میں گروپ کرنا، تکرار کی فریکوئنسی کا تجزیہ کرنا، اور breadcrumbs — غلطی سے پہلے صارف کے اعمال کی ترتیب — کے طور پر عملدرآمد کا سیاق و سباق فراہم کرنا ہے۔

غیر مہلک غلطیوں کو لاگ کرنے کے معیار

تمام غیر مہلک غلطیوں کو لاگ کرنے کی ضرورت نہیں ہے۔ متوقع حالتیں — کنکشن نہ ہونے پر نیٹ ورک کی ناکامی — انتخابی طور پر لاگ کی جا سکتی ہیں۔ غیر متوقع غلطیاں — ہینڈل شدہ کوڈ میں NullPointerException، غلط ڈیٹا فارمیٹ، منطقی غلطیاں — ہمیشہ لاگ ہونی چاہئیں۔ ہر ٹیم اپنی اہمیت کی حد متعین کرتی ہے: اوسطاً، روزانہ 1000 صارفین میں 10 سے 20 منفرد غیر مہلک غلطیاں معمول سمجھی جاتی ہیں۔ غیر مہلک غلطیوں میں تیزی سے اضافے کے لیے الرٹ سیٹ کرنا اہم ہے — یہ نئے API ورژن کے مسائل یا ریلیز کے بعد رجعت کی نشاندہی کر سکتا ہے۔

کوڈ میں غیر مہلک غلطیوں کا ہینڈلنگ

بنیادی ہینڈلنگ میکانزم try-catch ہے، جو استثناء کو پکڑتا ہے اور بحالی کوڈ کو انجام دیتا ہے۔ نیٹ ورک آپریشنز کے لیے، عام پیٹرن ایکسپونیشنل بیک آف کے ساتھ دوبارہ کوشش ہے۔ پارسنگ کی غلطیوں کے لیے، طریقہ ڈیفالٹ فال بیک ویلیوز استعمال کرنا اور بعد میں سرور سائڈ تجزیہ کے لیے سیاق و سباق کو لاگ کرنا ہے۔

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 اقسام — استثناء کے بغیر ایک متبادل طریقہ۔ ایک فنکشن Success اور Failure کے ورینٹس کے ساتھ sealed کلاس Result لوٹاتا ہے۔ کال کرنے والا کوڈ دونوں ورینٹس کو واضح طور پر ہینڈل کرتا ہے، غیر ہینڈل شدہ غلطیوں کو ختم کرتا ہے۔ Result اقسام Kotlin (معیاری لائبریری میں Result) اور Swift (Result) میں ٹائپ لیول پر غیر مہلک حالتوں کے واضح ہینڈلنگ کے لیے مقبول ہیں۔

غیر مہلک غلطیوں کے لیے فال بیک حکمت عملی

غیر مہلک غلطی کی ہر قسم کے لیے ایک بحالی کی حکمت عملی منصوبہ بندی کرنی چاہیے: نیٹ ورک کی غلطی پر کیشڈ ڈیٹا لوڈ کرنا، پارسنگ کی غلطی پر ڈیفالٹ ویلیوز استعمال کرنا، UI غلطی پر کمپوننٹ کو دوبارہ شروع کرنا۔ ایک اچھا عمل یہ ہے کہ صارف کو ایپلیکیشن کے ساتھ تعامل کو مکمل طور پر روکے بغیر ایرر میسیج کے ساتھ ٹوسٹ یا سنیک بار دکھایا جائے۔ بحالی کے قابل اور ناقابل بحالی غلطیوں کے درمیان فرق کرنا اہم ہے „ بعد والی کے لیے، بحالی کی حکمت عملی مختلف ہوگی، جیسے اسکرین دوبارہ شروع کرنے یا ڈیٹا صاف کرنے کا مشورہ دینا۔ پچھلی کامیاب حالت کو کیش کرنا اکثر موبائل پلیٹ فارمز پر غیر مہلک غلطیوں کو ہینڈل کرنے کا سب سے آسان اور مؤثر طریقہ ہے۔