Then the call site looks super tidy: ``` fun getIn...

# coroutines

[scottiedog45]

Then the call site looks super tidy:

fun getInvoice(id: String) {
        
        launchWithErrorHandling {

            val invoice = repository.getInvoice(id)
            _showSuccess.postValue(invoice)
        }
    }

[Tash]

Similar to what @streetsofboston mentioned, at the ViewModel layer, it might be more helpful to catch “domain specific” exceptions. At the repository layer, if the specific exceptions are caught and remodeled as “domain specific” exceptions such as `NetworkError`/`InvalidInvoice`/`ErrorRetrievingInvoice` etc, then at the ViewModel, you could catch those instead of a catch-all.

[streetsofboston]

Yup. And you could get rid of 'expected' exceptions entirely (and only have truly fatal exceptions crash your app). Use Result<E, T> or Either<E, T> as return types instead, where E is your error-type (sealed class hierarchy?) and T is the return type.

[streetsofboston]

Since Kotlin no longer has checked exceptions, using Result or Either types will force you to think about your error modelling.