wathek
08/07/2019, 5:07 PM// First method
val test = Mono.just("hello").run { block() }
// Second method
val test = Mono.just("hello").block()
Both cases test
has String?
typekarelpeeters
08/07/2019, 5:10 PMblock
in the first one doesn't have to be defined on the subject, it can be a top level function or something from the surrounding scope.wathek
08/07/2019, 5:27 PMinappropriate blocking method call
and it suggests to write it either using run
or with
karelpeeters
08/07/2019, 5:27 PMwhen
? Are you sure? And is this in a coroutine context or something?wathek
08/07/2019, 5:28 PMwith
Mono
karelpeeters
08/07/2019, 5:29 PMwathek
08/07/2019, 5:33 PMkarelpeeters
08/07/2019, 5:34 PMblock
come from then?wathek
08/07/2019, 5:36 PMMono
according to the documentation
* Subscribe to this {@link Mono} and <strong>block indefinitely</strong> until a next signal is
* received. Returns that value, or null if the Mono completes empty. In case the Mono
* errors, the original exception is thrown (wrapped in a {@link RuntimeException} if
* it was a checked exception).
karelpeeters
08/07/2019, 5:40 PMrun
or with
would help unless Mono has specific versions as well.wathek
08/07/2019, 5:41 PMwasyl
08/08/2019, 7:46 AM.run { block() }
isn’t detected by that particular inspectioninappropriate thread-blocking method call
and see if the warning goes away. The description says Reports thread-blocking method calls found in a code fragment where a thread should not be blocked (e.g. Reactive frameworks, Kotlin coroutines)
so there’s good chance it’s just IntelliJ being helpful and saying you shouldn’t be using blocking methods in reactive frameworkskarelpeeters
08/08/2019, 8:31 AMrun
or with
help at all? They just shuffle parameter names around, they don't change anything about the blocking.wasyl
08/08/2019, 8:53 AMblock
on Mono
type, and not within Mono
scope. I’d guess .let { it.block() }
would also show a warningkarelpeeters
08/08/2019, 3:47 PM@Supress
?wasyl
08/08/2019, 6:01 PM