Where should exception handling occur within a clean architecture?

[SanEffect]

Hello!
I'm trying to figure out where and how exception handling should happen.
I noticed that in your samples you practically do not use a custom class Result. It is only used in NowInAndroid, and only at the presentation level to determine UI state (asResult() method).
My project uses clean architecture and I'm used to handling exceptions on a data layer. I use the following method to call db operations:

suspend fun <T> doQuery(
     dispatcher: CoroutineDispatcher = ioDispatcher,
     action: suspend() -> T
): Result<T> = withContext(dispatcher) {
     try {
         Result.Success(action.invoke())
     } catch (e: Exception) {
         Result.Failure(e)
     }
}

It is used in repositories like so:

suspend fun saveRecord(record: RecordEntity): Result<String> =
     doQuery { recordsDataSource.updateRecord(record.toLocal()) }

I see two problems with this approach:

1. Method signatures are "overloaded" with an extra type (Result)
2. It's a little more difficult to work with tests because we have to process the Result class. Cast to "Success" or "Failure" each time

As I already said, in your projects you practically do not use a custom Result class. And so I began to doubt that I was doing everything right. How and where do you handle exceptions? Do I need to do this on a data layer or is it better to move try-catch blocks to a presentation layer?
If we do exception handling at a presentation level (try-catch), then this will get rid of "overloaded" method signatures and make it easier to work with tests, however, I'm not sure if this is the right approach.
I mean that on a data layer we can leave try-catch processing, but not return Result. At a presentation level, use this method for suspends:

suspend fun <T> getResult(action: suspend () -> T) = try {
     Result.Success(action.invoke())
} catch (e: Exception) {
     Result.Failure(e)
}

And then use it something like this:

getResult { saveRecordUseCase(record) }.let { result -> 
    when (result) {
        is Result.Success -> {}
        is Result.Failure -> {}
    }
}

[Omasyo]

I handle my exceptions the first way. Then I use it like:

suspend fun useFunction(record: RecordEntity): String {
     return doQuery { recordsDataSource.updateRecord(record.toLocal()) }
        .fold(onSuccess = { it }) { "Error" }
}

and I don't have any problems with writing tests, it actually works pretty well. No need for casts

(The outer lamda runs on error)

[jocoand]

One of the caveats of catching exceptions in the presentation layer is the difficulty in handling the variety of exceptions. The presentation layer wouldn't/shouldn't know what kind of exceptions might occur there.

By handling exceptions in the data layer, we can decide which exceptions need to be handled and which do not.
Then, we also can determine how to handle these exceptions, such as mapping them to our custom error model.

[jocoand]

Regarding the sample, it seems the exceptions are still not mentioned in the documentation. Because they are not mentioned, in my opinion, being in the sample doesn't mean it is the recommended approach, as the documentation and samples are still being updated.