+ is there any difference between putting a runInt...

# arrow

[Fred Friis]

+ is there any difference between putting a runInterruptible inside an either catch vs outside it?

suspend fun <T> queryForList(arguments): Either<DbError, List<T>> {
      return Either
         .catch {
            runInterruptible(<http://Dispatchers.IO|Dispatchers.IO>) {
               jdbcTemplate.queryForStream(sql, args, mapper).use { it.toList() } 
            } 
         }.mapLeft { DbError.TalkToDbError() }
   }

suspend fun <T> queryForList(arguments): Either<DbError, List<T>> {
      return runInterruptible(<http://Dispatchers.IO|Dispatchers.IO>) {
         Either
            .catch { jdbcTemplate.queryForStream(sql, args, mapper).use { it.toList() } }
            .mapLeft { DbError.TalkToDbError() }
      }
   }

or are they identical in practice?

to be clear, the suspend fun type signature ends up the same, I guess I'm wondering if there's any difference in execution eg if the parent coroutine calling this db call coroutine gets cancelled/interrupted and it tries to cancel the child etc

[simon.vergauwen]

There is no difference. runInterruptible does something completely independent and calls and returns immediately.

[Fred Friis]

and using runInterruptible for blocking jdbcCalls is the correct, idiomatic way to make such blocking calls from an asynch suspend context, right? my understanding is it bridges that gap between suspend and blocking code and gives you a suspension point (blocking code will never be asynch but it does what can and should be done basically)

[simon.vergauwen]

Yep, that’s correct. It calls Thread.interrupt on Job.cancel if I’m not mistaken. And translated ThreadInterruptedException into CancellationException.