Designing for Errors in a Kotlin-first SDK:When to throw, nullify, or return a Result.
summary
The Kotlin-first SDK migration revisits error strategy across about 2,000 functions built atop a C++ core with JNI and finds three actionable patterns: throw and annotate with @Throws for preventable logic errors; use sealed-result shapes for recoverable domain errors but prefer a returned Result to avoid breaking changes when native layers may add new error cases; and use nullable/boolean/empty-collection returns (with orNull/try naming) for lenient errors. Suspend functions mostly return Result for I/O, properties avoid throwing, and constructors use factories when nontrivial failure handling is needed.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 1:07Why error design matters
- 2:31Kotlin error propagation
- 4:55Domain-specific errors
- 7:21Lenient error handling
- 10:54Case study and constraints
- 14:43Suspend functions and properties
- 16:11Summary and resources
- 16:33Q&A
