Разумно ли выбрасывать исключение из асинхронного метода?

IMO, вариант 1) усложняет использование API, потому что будет два разных пути для сообщения об ошибках:

1. «Синхронные» исключения, где метод завершает генерируемое исключение. [ 1111]
2. «Асинхронные» исключения, где метод возвращает CF, что завершается исключением. Обратите внимание, что избежать этого случая невозможно, потому что всегда будут ситуации, когда ошибки обнаруживаются только после запуска асинхронного пути (например, тайм-ауты).

Теперь программист должен убедиться, что оба эти пути правильно обработаны, а не один.

Интересно также отметить, что поведение как для C #, так и для Javascript заключается в том, чтобы всегда сообщать об исключениях, выбрасываемых внутри тела функции async через возвращаемые Task / Promise, даже для исключений, выданных перед первым await, и никогда не заканчивая вызов функции async исключением.

То же самое верно и для сопрограмм Котлина, даже при использовании диспетчера Unconfined

class SynchronousExceptionExamples {
    @Test
    fun example() {
        log.info("before launch")
        val job = GlobalScope.launch(Dispatchers.Unconfined) {
            log.info("before throw")
            throw Exception("an-error")
        }
        log.info("after launch")
        Thread.sleep(1000)
        assertTrue(job.isCancelled)
    }
}

будет получено примечание

6 [main] INFO SynchronousExceptionExamples - before launch
73 [main @coroutine#1] INFO SynchronousExceptionExamples - before throw
(...)
90 [main] INFO SynchronousExceptionExamples - after launch

, поскольку исключение происходит в main нить, однако launch заканчивается правильным Job.

Я думаю, что оба являются действительными проектами. Datastax фактически начал свою разработку с первого подхода, когда заимствование соединения блокировалось, и переключился на полностью асинхронную модель ( https://docs.datastax.com/en/developer/java-driver/3.5/upgrade_guide/#3 -0-4 )

Как пользователь jav-драйвера datastax, я был очень доволен исправлением, так как оно изменило API на действительно неблокирующее (даже открывая канал, в вашем примере, имеет стоимость).

Но я не думаю, что здесь есть что-то правильное и неправильное ...

Это не имеет большого значения с точки зрения абонентов. В любом случае будет видна причина исключения, независимо от того, было ли оно выброшено из метода или из вызова get () в завершаемом будущем.

Возможно, я бы поспорил, что исключение, создаваемое завершаемым будущим, должно быть исключением из асинхронных вычислений и не должно начинать эти вычисления.