Beyond Exceptions: Building Resilient Android Apps with Safety-Critical Principles

When your Android app crashes, users uninstall. This session explores how to handle failures before they become crashes, focusing on Android's unique reliability challenges.

We'll establish the critical distinction between domain errors (expected business logic failures) and system failures (unrecoverable hardware/OS issues), implementing each with appropriate strategies. You'll learn to build a custom Result monad that provides compile-time safety beyond Kotlin's built-in limitations, and we'll see how NASA's mission-critical safety rules can be applied in the Android world. You'll also master native crash debugging techniques for those unavoidable system failures.

From handling hardware state corruption to graceful degradation under memory pressure, you'll walk away with battle-tested patterns for Android's trickiest reliability scenarios: complex state management, native code integration, and building apps that degrade gracefully rather than crash catastrophically.

Target audience: Individual contributors and engineering managers looking to improve app stability and reduce crash rates through principled error handling.

Transcript

1. Beyond Exceptions Building Resilient Android Apps with Safety-Critical Principles
2. Bogusz Pawłowski Sta ff Engineer @SpotOn Slides + examples
3. Bogusz Pawłowski Sta ff Engineer @SpotOn • Complex restaurant POS system
4. Bogusz Pawłowski Sta ff Engineer @SpotOn • Complex restaurant POS system • O ff line- f irst approach
5. Bogusz Pawłowski Sta ff Engineer @SpotOn • Complex restaurant POS system • O ff line- f irst approach • Most of the logic on the client side
6. Bogusz Pawłowski Sta ff Engineer @SpotOn • Complex restaurant POS system • O ff line- f irst approach • Most of the logic on the client side • Multiple applications with local and IP communication
7. Bogusz Pawłowski • Complex restaurant POS system • O ff line- f irst approach • Most of the logic on the client side • Multiple applications with local and IP communication • Huge domain Sta ff Engineer @SpotOn
8. Bogusz Pawłowski • High potential for errors Sta ff Engineer @SpotOn
9. I 💜 Kotlin
10. but
11. Error Handling in Kotlin feels all over the place
12. Brief History of Kotlin Error Handling
13. Lets start with Java
15. Java 17 SE documentation “The class Exception and its subclasses are a form of Throwable that indicates conditions that a reasonable application might want to catch.” “An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.”
16. Checked Exceptions
17. Checked Exceptions PhoneNumber toPhoneNumber(String rawNumber) throws NumberFormatException
18. The Problem(s)
19. Kotlin: Unchecked Exceptions
20. How are we supposed to model errors?
21. How are we supposed to model errors? What are exceptions in Kotlin for?
22. Error de f inition
23. Domain Errors - unhappy scenarios
24. Domain Errors - unhappy scenarios Program Logic Errors - programmer mistakes
25. Domain Errors Program Logic Errors Are anticipated? Can be handled gracefully? What Kotlin features should we use?
26. Domain Errors Program Logic Errors Are anticipated? Yes Can be handled gracefully? What Kotlin features should we use?
27. Domain Errors Program Logic Errors Are anticipated? Yes No Can be handled gracefully? What Kotlin features should we use?
28. Domain Errors Program Logic Errors Are anticipated? Yes No Can be handled gracefully? Always What Kotlin features should we use?
29. Domain Errors Program Logic Errors Are anticipated? Yes No Can be handled gracefully? Always Usually no What Kotlin features should we use?
30. Domain Errors Program Logic Errors Are anticipated? Yes No Can be handled gracefully? Always Usually no What Kotlin features should we use? ? ?
31. Domain Errors
32. @JvmInline value class PhoneNumber(val raw: String)
33. @JvmInline value class PhoneNumber(val raw: String) fun String.toPhoneNumber(): PhoneNumber
34. Exceptions
35. fun String.toPhoneNumber(): PhoneNumber { if (matches(regex =fPatterns.PHONE.toRegex()) { return PhoneNumber(this) } else { throw IllegalArgumentException("Number is invalid”)f } }
36. val invalidInput = "123132123a" val phoneNumber: PhoneNumber = invalidInput.toPhoneNumber() println("Acquired phone number: $phoneNumber") fun String.toPhoneNumber(): PhoneNumber
37. val invalidInput = "123132123a" val phoneNumber: PhoneNumber = invalidInput.toPhoneNumber() println("Acquired phone number: $phoneNumber") 💥 fun String.toPhoneNumber(): PhoneNumber
38. val invalidInput = "123132123a" try { val phoneNumber: PhoneNumber = invalidInput.toPhoneNumber() println("Acquired phone number: $phoneNumber") } catch (e: IllegalArgumentException) { println("Failed to acquire phone number: ${e.message}") } fun String.toPhoneNumber(): PhoneNumber
39. val invalidInput = "123132123a" // Requires knowledge of implementation details to handle the exception. try { val phoneNumber: PhoneNumber = invalidInput.toPhoneNumber() println("Acquired phone number: $phoneNumber") } catch (e: IllegalArgumentException) { println("Failed to acquire phone number: ${e.message}") } fun String.toPhoneNumber(): PhoneNumber
40. val invalidInput = "123132123a" // Requires knowledge of implementation details to handle the exception. try { val phoneNumber: PhoneNumber = invalidInput.toPhoneNumber() println("Acquired phone number: $phoneNumber”) // We collect whole stack trace, which is completely pointless } catch (e: IllegalArgumentException) { println("Failed to acquire phone number: ${e.message}") } fun String.toPhoneNumber(): PhoneNumber
41. Nullability
42. Nullability fun String.toIntOrNull(): Int?
43. fun String.toPhoneNumberOrNull(): PhoneNumber?f{ return if (matches(regex =fPatterns.PHONE.toRegex()) { PhoneNumber(this) } else { null } }
44. fun String.toPhoneNumberOrNull(): PhoneNumber?f val invalidInput = "123132123a" val phoneNumber: PhoneNumber? = invalidInput.toPhoneNumberOrNull()
45. val invalidInput = "123132123a" val phoneNumber: PhoneNumber? = invalidInput.toPhoneNumberOrNull() if (phoneNumber == null) { println("Failed to acquire phone number: Invalid input provided") } else { println("Acquired phone number: ${phoneNumber.raw}") } fun String.toPhoneNumberOrNull(): PhoneNumber?
46. val invalidInput = "123132123a" val phoneNumber: PhoneNumber? = invalidInput.toPhoneNumberOrNull() if (phoneNumber == null) { // This requires knowledge of implementation details println("Failed to acquire phone number: Invalid input provided") } else { println("Acquired phone number: ${phoneNumber.raw}") } fun String.toPhoneNumberOrNull(): PhoneNumber?
47. val invalidInput = "123132123a" val phoneNumber: PhoneNumber? = invalidInput.toPhoneNumberOrNull() // We are limited to only one possible error case if (phoneNumber == null) { // This requires knowledge of implementation details println("Failed to acquire phone number: Invalid input provided") } else { println("Acquired phone number: ${phoneNumber.raw}") } fun String.toPhoneNumberOrNull(): PhoneNumber?
48. What about more complex error handling?
49. Kotlin Result<T>
50. fun String.toPhoneNumber(): Result<PhoneNumber>f{f return if (isBlank())f{f Result.failure(IllegalArgumentException("Number cannot be blank")) } else if (!matches(regex =fPatterns.PHONE.toRegex()))f{f Result.failure(IllegalArgumentException("Invalid phonefnumber")) } elsef{f Result.success(PhoneNumber(this)) }f }ff
51. val invalidInput = "123132123a" val phoneNumberResult: Result<PhoneNumber> = invalidInput.toPhoneNumber() phoneNumberResult.onSuccess { phoneNumber -> println("Acquired phone number: ${phoneNumber.raw}") } fun String.toPhoneNumber(): Result<PhoneNumber>
52. val invalidInput = "123132123a" val phoneNumberResult: Result<PhoneNumber> = invalidInput.toPhoneNumber() phoneNumberResult.onSuccess { phoneNumber -> println("Acquired phone number: ${phoneNumber.raw}") }.onFailure { exception -> when (exception) { is IllegalArgumentException -> { TODO() } else -> { println("An unexpected error occurred") } } } fun String.toPhoneNumber(): Result<PhoneNumber>
53. phoneNumberResult.onFailure { exception -> when (exception) { is IllegalArgumentException ->f{ TODO() } else -> { println("An unexpected error occurred") } } } fun String.toPhoneNumber(): Result<PhoneNumber>
54. phoneNumberResult.onFailure { exception -> when (exception) { is IllegalArgumentException ->f{ when (exception.message) { "Number cannot be blank" -> println("Number cannot be blank") "Invalid phone number" -> println("$invalidInput is invalid") else -> println("An unexpected error occurred”) } } else -> { println("An unexpected error occurred") } } } fun String.toPhoneNumber(): Result<PhoneNumber>
55. phoneNumberResult.onFailure { exception -> when (exception) { // Pointless exception creation is IllegalArgumentException -> { when (exception.message) { "Number cannot be blank" -> println("Number cannot be blank") "Invalid phone number" -> println("$invalidInput is invalid") else -> println("An unexpected error occurred”) } } else -> { println("An unexpected error occurred") } } } fun String.toPhoneNumber(): Result<PhoneNumber>
56. phoneNumberResult.onFailure { exception -> when (exception) { // Pointless exception creation is IllegalArgumentException -> { when (exception.message) { "Number cannot be blank" -> println("Number cannot be blank") "Invalid phone number" -> println("$invalidInput is invalid") else -> println("An unexpected error occurred”) } } // This will never be exhaustive, requires implementation knowledge else -> { println("An unexpected error occurred") } } } fun String.toPhoneNumber(): Result<PhoneNumber>
57. phoneNumberResult.onFailure { exception -> when (exception) { // Pointless exception creation is IllegalArgumentException -> { when (exception.message) { "Number cannot be blank" -> println("Number cannot be blank") "Invalid phone number" -> println("$invalidInput is invalid") else -> println("An unexpected error occurred”) } } // This will never be exhaustive, requires implementation knowledge // When the implementation changes, we won’t know about it. else -> { println("An unexpected error occurred") } } } fun String.toPhoneNumber(): Result<PhoneNumber>
58. Result.runCatching
59. https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/result.md#use-cases “The Result class is designed to capture generic failures of Kotlin functions for their latter processing and should be used in general-purpose API like futures (…). The Result class is not designed to represent domain-speci f ic error conditions.”
60. https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/result.md#use-cases “The Result class is designed to capture generic failures of Kotlin functions for their latter processing and should be used in general-purpose API like futures, etc, that deal with invocation of Kotlin code blocks and must be able to represent both a successful and a failed result of execution. The Result class is not designed to represent domain-speci f ic error conditions.” “In general, if some API requires its callers to handle failures locally (…), then it should use nullable types, when these failures do not carry additional business meaning, or domain-speci f ic data types to represent its successful results and failures (…)”
61. Sealed Hierarchies
62. Sealed Hierarchies + Custom Result
63. sealed interface PhoneValidationError { data object BlankNumber : PhoneValidationError data object InvalidFormat : PhoneValidationError }
64. sealed interface Result<out T, out E> { data class Success<T>(val value: T) : Result<T, Nothing> data class Failure<E>(val error: E) : Result<Nothing, E> }
65. fun String.toPhoneNumber(): Result<PhoneNumber, PhoneValidationError> { return when { this.isBlank() -> Result.Failure(PhoneValidationError.BlankNumber) !this.matches(regex = Patterns.PHONE.toRegex()) -> Result.Failure( PhoneValidationError.InvalidFormat ) else -> Result.Success(PhoneNumber(this)) } }
66. val invalidInput = "123132123a" val phoneNumberResult: Result<PhoneNumber, PhoneValidationError> = invalidInput.toPhoneNumber() when (phoneNumberResult) { is Result.Success -> TODO() is Result.Failure -> TODO() } fun String.toPhoneNumber(): Result<PhoneNumber, PhoneValidationError>
67. val invalidInput = "123132123a" val phoneNumberResult: Result<PhoneNumber, PhoneValidationError> = invalidInput.toPhoneNumber() when (phoneNumberResult) { is Result.Success -> println("Acquired phone number: $phoneNumberResult") is Result.Failure -> { when (phoneNumberResult.error) { BlankNumber -> TODO() InvalidFormat -> TODO() } } } fun String.toPhoneNumber(): Result<PhoneNumber, PhoneValidationError>
68. val invalidInput = "123132123a" val phoneNumberResult: Result<PhoneNumber, PhoneValidationError> = invalidInput.toPhoneNumber() when (phoneNumberResult) { is Result.Success -> println("Acquired phone number: $phoneNumberResult") is Result.Failure -> { when (phoneNumberResult.error) { BlankNumber -> TODO() InvalidFormat -> TODO() // No ‘else’!! } } } fun String.toPhoneNumber(): Result<PhoneNumber, PhoneValidationError>
69. val invalidInput = "123132123a" val phoneNumberResult: Result<PhoneNumber, PhoneValidationError> = invalidInput.toPhoneNumber() when (phoneNumberResult) { is Result.Success -> println("Acquired phone number: $phoneNumberResult") is Result.Failure -> { when (phoneNumberResult.error) { BlankNumber -> println("Invalid input: Phone number cannot be blank") InvalidFormat -> println("Invalid format for number $invalidInput") } } } fun String.toPhoneNumber(): Result<PhoneNumber, PhoneValidationError>
70. sealed interface CommonError { interface BlankInput : CommonError } fun handleCommonErrors(error: CommonError) { when (error) { is CommonError.BlankInput -> println("Error: Input cannot be blank") } }
71. sealed interface CommonError { interface BlankInput : CommonError } fun handleCommonErrors(error: CommonError) { when (error) { is CommonError.BlankInput -> println("Error: Input cannot be blank") } } sealed interface PhoneValidationError { data object BlankNumber : PhoneValidationError data object InvalidFormat : PhoneValidationError }
72. sealed interface CommonError { interface BlankInput : CommonError } fun handleCommonErrors(error: CommonError) { when (error) { is CommonError.BlankInput -> println("Error: Input cannot be blank") } } sealed interface PhoneValidationError { data object BlankNumber : PhoneValidationError, CommonError.BlankInput data object InvalidFormat : PhoneValidationError }
73. when (phoneNumberResult) { is Result.Success -> println("Acquired phone number: $phoneNumberResult") is Result.Failure -> { when (phoneNumberResult.error) { BlankNumber -> println("Invalid input: Phone number cannot be blank") InvalidFormat -> println("Invalid format for number $invalidInput") } } } fun String.toPhoneNumber(): Result<PhoneNumber, PhoneValidationError>
74. when (phoneNumberResult) { is Result.Success -> println("Acquired phone number: $phoneNumberResult") is Result.Failure -> { when (phoneNumberResult.error) { is BlankNumber -> handleCommonError(phoneNumberResult.error) InvalidFormat -> println("Invalid format for number $invalidInput") } } } fun String.toPhoneNumber(): Result<PhoneNumber, PhoneValidationError>
75. Domain Error handling in Kotlin is a mess
76. type PhoneNumber struct { Raw string } func ToPhoneNumber(s string) (PhoneNumber, error) { if strings.TrimSpace(s) == "" { return nil, errors.New("number cannot be blank") } return PhoneNumber{Raw: s}, nil }
77. type PhoneNumber struct { Raw string } func ToPhoneNumber(s string) (PhoneNumber, error) { if strings.TrimSpace(s) == "" { return nil, errors.New("number cannot be blank") } return PhoneNumber{Raw: s}, nil } func main() { invalidInput := " " phoneNumber, err := ToPhoneNumber(invalidInput) if err != nil { fmt.Printf("Failed to acquire phone number: %v\n", err) return } fmt.Printf("Acquired phone number: %+v\n", phoneNumber) }
78. Kotlin 2.4 - Rich Errors
79. error class BlankInputError error class InvalidFormatError
80. error class BlankInputError error class InvalidFormatError fun String.toPhoneNumber(): PhoneNumber | BlankInputError | InvalidFormatError { return when { this.isBlank() -> BlankInputError !this.matches(regex = Patterns.PHONE.toRegex()) -> InvalidFormatError else -> PhoneNumber(this) } }
82. val invalidInput = "123132123a" val phoneNumberResult: PhoneNumber | BlankInputError | InvalidFormatError = invalidInput.toPhoneNumber() when (phoneNumberResult) { is PhoneNumber -> println("Acquired phone number: $phoneNumberResult") is BlankInputError -> handleCommonErrors(BlankInputError) is InvalidPhoneNumberFormatError -> println("Invalid format") } fun String.toPhoneNumber(): PhoneNumber | BlankInputError | InvalidFormatError
83. val invalidInput = "123132123a" val phoneNumberResult: PhoneNumber | BlankInputError | InvalidFormatError = invalidInput.toPhoneNumber() // Safe call (?.) and double bang (!!.) will be available when (phoneNumberResult) { is PhoneNumber -> println("Acquired phone number: $phoneNumberResult") is BlankInputError -> handleCommonErrors(BlankInputError) is InvalidPhoneNumberFormatError -> println("Invalid format") } fun String.toPhoneNumber(): PhoneNumber | BlankInputError | InvalidFormatError
84. Simple error scenarios: Nullability Complex error scenarios: Sealed hierarchies + custom Result (to be superseded by Rich Errors)
85. Program Logic Failures
86. Noticing any unexpected errors as soon as possible is crucial
87. The Power of Ten – Rules for Developing Safety Critical Code “Rule: The assertion density of the code should average to a minimum of 2 assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life execution ”
88. We can leverage exceptions to spot program logic failures faster
89. We can leverage exceptions to spot program logic failures faster fun String.toInt(): Int
90. We can leverage exceptions to spot program logic failures faster class Cart { var order: Order? = null fun pay(amount: Double) { require(amount > 0) { "Amount must be greater than zero" } check(order != null) { "Order must be set before payment" } } }
91. Fuzz Testing
92. Fuzz Testing tigerbeetle.com
93. Screen Of Death
94. Screen Of Death
95. Summary
96. 1. Di ff erentiate between di ff erent error types
97. 1. Di ff erentiate between di ff erent error types 2. Handle your domain errors same way you handle success 1. Use nulls to handle simple error cases 2. Use sealed hierarchies to handle more complex errors 3. When interacting with 3rd party software be sure to guard edges of your system
98. 1. Di ff erentiate between di ff erent error types 2. Handle your domain errors same way you handle success 1. Use nulls to handle simple error cases 2. Use sealed hierarchies to handle more complex errors 3. When interacting with 3rd party software be sure to guard edges of your system 3. Use exceptions to spot and f ix program logic failures ASAP 1. Do not be afraid to crash the program, especially in debug 2. Add tools to enable developers to easily report a bug
99. Debugging native crashes
102. ͋Γ͕ͱ͏͍͟͝·͢
103. • https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07 • https://github.com/Kotlin/KEEP/blob/main/proposals/stdlib/KEEP-0127-result.md • https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441-rich-errors-motivation.md • https://spinroot.com/gerard/pdf/P10.pdf • https://github.com/tigerbeetle/tigerbeetle • https://source.android.com/docs/core/tests/debug/native-crash