Xử lý lỗi trong phát triển di động: khái niệm, kỹ thuật và cách tổ chức

Xử lý lỗi trong iOS: Do-Catch, Throw, Guard Let

Xử lý lỗi trong Swift được xây dựng trên bốn cơ chế chính: do-catch, throws, guard let và if-let. Không giống như nhiều ngôn ngữ, Swift không cho phép ngoại lệ không được bắt — mọi lỗi phải được xử lý rõ ràng hoặc khai báo thông qua throws. Xử lý lỗi là kỹ năng quan trọng cho phát triển di động, ảnh hưởng trực tiếp đến độ ổn định của ứng dụng.

Do-Catch và Throw

do-catch là khối tiêu chuẩn để gọi các hàm được đánh dấu bằng throws. Bên trong do, một hàm được gọi với try, và nếu nó ném ra lỗi, quyền điều khiển chuyển sang catch. Có thể xử lý các loại lỗi khác nhau thông qua pattern matching. Nếu lỗi không được xử lý, nó sẽ lan truyền lên trên ngăn xếp (Error Propagation). Để xử lý lỗi hiệu quả trong iOS, hãy sử dụng do-catch làm cơ chế chính.

Throw được khai báo trong chữ ký hàm: func fetchData() throws -> Data. Điều này có nghĩa là mã gọi phải xử lý lỗi thông qua try, try? hoặc try!. try? chuyển đổi lỗi thành nil, try! gây ra sự cố khi có lỗi (chỉ sử dụng nếu bạn chắc chắn thành công). Xử lý lỗi thông qua throw là thực hành bắt buộc trong Swift.

Optional/Nullable và Guard Let

Guard let là cấu trúc để thoát sớm khỏi hàm nếu giá trị là nil. Không giống như if-let, guard let yêu cầu một lối thoát (return, throw, break) trong nhánh else. Điều này làm cho mã phẳng hơn và dễ đọc hơn — không có khối if lồng nhau. Nếu optional không thể là nil — hãy sử dụng force unwrap (!), chỉ khi hoàn toàn chắc chắn. Trong ứng dụng di động, guard let giúp tránh sự cố khi xử lý các giá trị tùy chọn.

Optional Chaining (user?.address?.city) và nil-coalescing (??) là đường cú pháp để làm việc với optional mà không cần mở gói. Tại IT Sectr, chúng tôi sử dụng guard let để xác thực tham số đầu vào API và yêu cầu nhóm tránh force unwrap mà không có bình luận rõ ràng. Trình xử lý lỗi ở mọi cấp độ bảo vệ khỏi các lỗi không mong đợi.

Xử lý lỗi trong Android: Try-Catch, Elvis, Sealed Class

Kotlin là ngôn ngữ chính cho phát triển Android. Nó kế thừa try-catch từ Java nhưng bổ sung các lựa chọn thay thế an toàn hơn: toán tử elvis, require, check và sealed class. Xử lý lỗi trong Kotlin được xây dựng trên sự kết hợp của các cơ chế này. Không giống như Swift, Kotlin không yêu cầu xử lý các ngoại lệ đã kiểm tra (tất cả ngoại lệ đều không được kiểm tra). Để xử lý lỗi trong ứng dụng di động trên Android, hãy sử dụng sealed class làm mẫu chính.

Try-Catch và Toán tử Elvis

Try-catch trong Kotlin hoạt động như một biểu thức — nó trả về một giá trị. val result = try { fetchData() } catch (e: Exception) { fallbackValue }. Điều này làm giảm mã. Toán tử Elvis (?:) tương tự như nil-coalescing cho kiểu nullable: val name = user?.name ?: "Guest". Để xử lý lỗi trong ứng dụng di động, try-catch như một biểu thức là cách tiếp cận ngắn gọn nhất.

Sealed class là công cụ mạnh mẽ để mô hình hóa trạng thái thành công và lỗi. sealed class NetworkResult { data class Success(val data: T) : NetworkResult(); data class Error(val message: String) : NetworkResult() }. Khi được sử dụng trong biểu thức when, trình biên dịch kiểm tra tính đầy đủ của các nhánh. Xử lý lỗi thông qua sealed class đảm bảo không có trạng thái nào bị bỏ qua.

// Sealed class + try-catch — mẫu điển hình cho Android
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}")
    }
}

Trong ví dụ, sealed class NetworkResult mô hình hóa hai trạng thái: thành công với dữ liệu và lỗi với thông báo. Hàm fetchUser trả về kết quả trong mọi trường hợp và mã gọi xử lý cả hai nhánh thông qua when. Điều này loại bỏ khả năng lỗi không được xử lý. Xử lý lỗi thông qua sealed class là tiêu chuẩn cho phát triển Android tại IT Sectr.

Xử lý lỗi trong Kotlin: Result và Either

Result là kiểu tích hợp của Kotlin để biểu diễn kết quả của một hoạt động có thể thất bại. Nó buộc phải xử lý thành công và thất bại thông qua fold, getOrThrow hoặc map. Result hữu ích trong các chuỗi bất đồng bộ (coroutines). Xử lý lỗi với Result là tiêu chuẩn cho phát triển di động trong Kotlin.

Result vs Either

Either là kiểu hàm từ thư viện Arrow cho phép trả về giá trị của một trong hai kiểu (Left — lỗi, Right — thành công). Không giống như Result, Either có thể chứa bất kỳ kiểu lỗi nào do người dùng định nghĩa. Đối với dự án đơn giản, Result tích hợp là đủ; đối với dự án phức tạp, hãy sử dụng Either từ Arrow. Việc chọn công cụ xử lý lỗi phụ thuộc vào độ phức tạp của dự án.

Lan truyền lỗi

Lan truyền lỗi là cơ chế mà lỗi lan truyền lên trên ngăn xếp cuộc gọi cho đến khi được xử lý. Trong Kotlin, điều này xảy ra theo mặc định (ngoại lệ unchecked). Trong Swift, điều này chỉ áp dụng cho các hàm được đánh dấu bằng throws. Với Result và Either, lỗi không lan truyền — chúng ở trong kiểu và bạn phải xử lý chúng. Điều này làm cho việc xử lý lỗi trong ứng dụng di động an toàn hơn.

Bảng cho thấy sự khác biệt chính. iOS yêu cầu khai báo lỗi rõ ràng (throws), làm cho mã an toàn hơn nhưng dài dòng hơn. Android phụ thuộc vào kỷ luật của nhà phát triển. Tại IT Sectr, chúng tôi sử dụng sealed class cho Android và throws cho iOS — đây là thực hành tốt nhất của cả hai nền tảng để xử lý lỗi trong ứng dụng di động.

Báo cáo sự cố: Crashlytics và Sentry

Báo cáo sự cố là hệ thống thu thập và phân tích sự cố ứng dụng. Báo cáo sự cố là phần thiết yếu của xử lý lỗi trong môi trường sản xuất. Nếu không có nó, bạn biết về vấn đề từ người dùng, điều không thể chấp nhận cho sản xuất. Hai công cụ chính: Firebase Crashlytics (miễn phí) và Sentry (miễn phí cho sử dụng cơ bản). Để xử lý lỗi trong ứng dụng di động, hãy luôn triển khai báo cáo sự cố từ bản phát hành đầu tiên.

Firebase Crashlytics

Crashlytics là một phần của Firebase. Nó tự động thu thập sự cố, nhóm chúng theo ngăn xếp cuộc gọi và hiển thị số lượng người dùng bị ảnh hưởng. Nó hỗ trợ ghi nhật ký lỗi không nghiêm trọng thông qua recordException(). Tích hợp: thêm SDK vào build.gradle (Android) hoặc Podfile (iOS). Crashlytics là công cụ miễn phí tốt nhất để xử lý lỗi khi bắt đầu dự án.

Sentry

Sentry là hệ thống giám sát lỗi đa nền tảng. Không giống như Crashlytics, Sentry cung cấp theo dõi chi tiết (breadcrumbs), giám sát hiệu suất và hỗ trợ React Native. Nó cho phép xem trạng thái ứng dụng tại thời điểm xảy ra lỗi. IT Sectr khuyên dùng Sentry cho các dự án cần kiểm soát hoàn toàn việc xử lý lỗi trong phát triển di động.

Error Boundary trong React Native

Error Boundary là thành phần React bắt lỗi JavaScript trong cây thành phần con và hiển thị giao diện dự phòng, ngăn chặn sự cố toàn bộ ứng dụng. Error Boundary là thành phần chính để xử lý lỗi trong React Native. Sử dụng error boundaries cho các màn hình quan trọng và điều hướng. Xử lý lỗi trong ứng dụng di động trên React Native yêu cầu thiết lập Error Boundary thích hợp ở cấp cao nhất.

Triển khai Error Boundary

Error Boundary được tạo thông qua componentDidCatch(error, errorInfo) hoặc static getDerivedStateFromError(error). Nó không bắt lỗi trong mã bất đồng bộ (setTimeout, requestAnimationFrame), kết xuất phía máy chủ hoặc lỗi gốc (Native Modules). Để ghi nhật ký, hãy sử dụng SDK báo cáo sự cố bên trong componentDidCatch. Error Boundary là trình xử lý lỗi đơn giản nhưng hiệu quả cho lớp giao diện.

Lỗi nghiêm trọng và không nghiêm trọng

Lỗi nghiêm trọng là ngoại lệ không được xử lý gây ra sự cố ứng dụng. Lỗi không nghiêm trọng là ngoại lệ bạn đã bắt và xử lý, nhưng nó chỉ ra vấn đề trong mã. Lỗi không nghiêm trọng được ghi nhật ký qua Crashlytics/Sentry và giúp tìm lỗi trước khi chúng trở nên nghiêm trọng. Cả lỗi nghiêm trọng và không nghiêm trọng đều yêu cầu xử lý lỗi thích hợp trong phát triển di động.