Question 1

Bu kodda catch niyə işləmir: try { save(); } catch (e) { ... }, save() async-dır?

Accepted Answer

Cavabı mexanizmlə qur, üç addımda. 1. Birbaşa cavab: çünki await yoxdur — save() sinxron olaraq bir Future qaytarır, try bloku dərhal bitir, xəta isə sonra baş verir. 2. Niyəsi: await Future-un xətasını cari frame-ə bağlayan yeganə şeydir. await yoxdursa, xətanı tutacaq frame də yoxdur — o, zone-a qalxır və unhandled async error kimi bitir. 3. Həll variantları (burada namizədlərin çoxu dayanır — sən davam et): await save(); — ən sadə; niyyət həqiqətən fire-and-forget-dirsə unawaited(save().catchError(...)) — belə yazanda oxuyan adam bunun qəsdən olduğunu görür; bir neçə paralel çağırış varsa await Future.wait([...]). Sonunda profilaktikanı əlavə et: unawaited_futures lint qaydası bu səhvi CI-da tutur — mən onu bütün layihələrdə açıq saxlayıram.

Question 2

Dart-da Error və Exception fərqi nədir və sən hansını atırsan?

Accepted Answer

Əvvəlcə çox namizədin buraxdığı incəliyi vur: bu, dil qaydası deyil, konvensiyadır — catch (e) hər ikisini tutur, hətta throw 'string' da mümkündür (amma etmə). Sonra niyyət fərqini izah et: Exception — gözlənilən, bərpa oluna bilən hal (şəbəkə, parse, ödəniş rədd edildi); onu atırsan ki, çağıran tərəf tutsun. Error — proqramçı səhvi (ArgumentError, StateError, RangeError, TypeError); onu atırsan ki, kod düzəlsin, tutulmasın. Konkret nümunə ver: "Repository-də HTTP 402 gələndə PaymentDeclined implements Exception atıram — bu, biznes halıdır və UI onu istifadəçiyə göstərməlidir. Amma applyDiscount(150) çağırılıbsa, ArgumentError.value(...) atıram — bu, bug-dır və istifadəçiyə göstəriləsi bir şey deyil." Son olaraq dizayn detalını əlavə et: öz exception sinfimdə toString()-i həmişə override edirəm və mətn əvəzinə struktur sahələr (code, retryable) qoyuram ki, çağıran tərəf string parse etməsin.

Question 3

Stream-də xətaları necə emal edirsən? onError, handleError və await for arasında necə seçirsən?

Accepted Answer

Seçimi "xəta kimin problemidir" sualı ilə izah et — bu, cavaba struktur verir. listen(onError: ...) — xəta listener-in problemidir: göstər, log yaz. Vacib detal: default cancelOnError: false, yəni subscription xətadan sonra da yaşayır. Bunu bilmək interview-da fərq yaradır. handleError(..., test: ...) — xəta pipeline-ın problemidir: pozuq elementi atıb qalanını buraxmaq istəyirsən. test: ilə yalnız konkret tipi udmaq vacibdir, əks halda real bug-ları da udursan. await for + try/catch — ardıcıl emal edirsən və ilk xəta prosesi dayandırmalıdır; xəta dövrənin içinə atılır, ona görə adi try/catch işləyir, amma dövrə bitir. Konkret nümunə ilə tamamla: "WebSocket-dən gələn mesajları emal edirdik; parse xətası bütün stream-i öldürməməli idi, ona görə handleError(test: (e) => e is FormatException) ilə yalnız parse xətalarını udub metrikaya yazdıq, qalan xətalar isə listener-ə çatıb bağlantını yenidən qurmağa səbəb olurdu." Bir də əlavə et: StreamSubscription-ı mütləq cancel() etmək lazımdır — əks halda resurs sızması olur; bunu finally-də və ya obyektin dispose()-unda edirəm.

Question 4

Tətbiqdə qlobal xəta emalını necə qurardın ki, heç bir crash itməsin?

Accepted Answer

Bu, senior sualıdır — "laylar" modeli ilə cavab ver, tək API adı ilə yox. Lay 1 — lokal: hər I/O çağırışı öz try/catch-ində, typed on X catch ilə; bu, istifadəçiyə mənalı mesaj göstərməyin yeganə yoludur. Qlobal handler istifadəçi təcrübəsi üçün deyil. Lay 2 — zone: runZonedGuarded(() => startApp(), (error, stack) => reporter.capture(error, stack)). Bura yalnız heç kimin tutmadığı async xətalar düşür. Flutter tərəfində əlavə olaraq framework-ün öz handler-i də bağlanır, amma Dart səviyyəsində vacib olan budur ki, zone bütün async əməliyyatları əhatə edir — runZonedGuarded çağırışı main-in ən üstündə olmalıdır, əks halda ondan əvvəl yaradılmış Future-lar başqa zone-a aiddir. Lay 3 — isolate: ayrı isolate-də baş verən xəta əsas zone-a gəlmir. Isolate.current.addErrorListener və ya Isolate.run ətrafında try/catch lazımdır — bunu bilmək güclü siqnaldır. Keyfiyyət detalı: reporter-ə həmişə stack göndər və xətaları qruplaşdırıla bilən tiplərlə at; Error.throwWithStackTrace ilə büküb orijinal trace-i saxlayıram. PII (istifadəçi datası) log-a düşməməlidir — bunu da qeyd et, komanda yetkinliyini göstərir. Nə etməməli: runZonedGuarded içində xətanı "düzəltməyə" çalışmaq və ya bütün kodu bir nəhəng try/catch-ə bükmək — bu, bug-ları gizlədir.

Question 5

Repository layında xətaları exception kimi atmaq, yoxsa Result/sealed tipi qaytarmaq daha yaxşıdır?

Accepted Answer

Burada gözlənilən "düzgün cavab" yoxdur — səndən trade-off düşüncəsi gözləyirlər. Strukturu belə qur: hər variantın güclü tərəfi, zəif tərəfi, sənin seçim meyarın. Exception: dilin təbii yolu, kod qısa qalır, gözlənilməz hallar avtomatik yuxarı qalxır. Zəif tərəfi: imzada görünmür (Future xəta ata biləcəyini demir), ona görə çağıran tərəf hansı halları emal etməli olduğunu ancaq sənədlərdən bilir. sealed nəticə tipi (sealed class Result + Success/Failure): xəta halları tipin özündə görünür və Dart 3-də switch exhaustive olur — bir hal əlavə edəndə kompilyator bütün emal yerlərini göstərir. Zəif tərəfi: hər çağırış nöqtəsində açmaq lazımdır, kod bir az uzanır və hər şeyi belə yazmaq boğucu olur. Mənim meyarım: gözlənilən biznes halları — sealed tiplə (ödəniş rədd edildi, kod artıq istifadə olunub, sessiya bitib): bunlar UI-ın mütləq emal etməli olduğu axınlardır və unudulmamalıdır. Gözlənilməz texniki xətalar — exception kimi qalsın (şəbəkə düşdü, disk dolu, parse pozuldu): onları hər yerdə açmağın mənası yoxdur, üstdəki lay tutub crash reporting-ə göndərir. Sonunda praktik qeyd: nə seçsən, layı keçəndə çevir — HTTP status kodları və SocketException domain layına sızmamalıdır, orada NoConnection, Unauthorized kimi domain tipləri olmalıdır.

Mexanizm	Nəyi tutur	Nə vaxt istifadə edilir
`try/await/catch`	Sinxron `throw`-ları və `await` edilmiş Future-un xətasını	Default seçim — kodun 90%-i belə yazılır
`on FormatException catch (e, st)`	Yalnız həmin tipdəki xətanı, stack trace ilə birlikdə	Fərqli xəta tiplərinə fərqli reaksiya lazım olanda
`future.catchError(...)`	Həmin Future zəncirindəki xətanı; `test:` parametri ilə filtr edilə bilər	`await` mümkün olmayan yerlərdə (məs. `unawaited(...)` ilə fire-and-forget)
`future.then(onValue, onError: ...)`	Yalnız ƏVVƏLKİ mərhələnin xətasını — `onValue` içində atılan xətanı tutmur	İki halı ayırmaq lazım olanda; incə fərqinə görə interview-da tez-tez soruşulur
`stream.listen(onError: ..., cancelOnError: ...)`	Həmin subscription-a çatan xətaları (default olaraq subscription davam edir)	Listener tərəfində — UI-a xəta göstərmək, log yazmaq
`stream.handleError(..., test: ...)`	Pipeline-dan keçən xətaları — onları udur və ya çevirir	Stream-i emal edən zəncirin ortasında, listener-i təmiz saxlamaq üçün
`runZonedGuarded(body, onError)`	Zone daxilində heç kimin tutmadığı bütün async xətaları	Son müdafiə xətti — crash reporting (Sentry, Crashlytics)

Asinxron kodda xəta emalı

📚 Mənbələr və sənədlər