Ellen Spertus
10/28/2019, 6:45 PMVoid
and has the following behavior:
override fun getResult(): Void {
if (!success) throw RuntimeException()
}
This doesn't compile, because a function with a block body requires a return statement.Ruckus
10/28/2019, 6:48 PMVoid?
(remember Java doesn't have null safety).
override fun getResult(): Void? {
if (success) return null
else throw RuntimeException()
}
James
10/28/2019, 6:48 PMoverride fun getResult(): Unit {
if (!success) throw RuntimeException()
}
karelpeeters
10/28/2019, 6:49 PMJames
10/28/2019, 6:49 PMEllen Spertus
10/28/2019, 6:49 PMTask<Void>
, which requires implementing getResult(): Void
.override fun getResult(): Void {
throw RuntimeException()
}
Ruckus
10/28/2019, 6:51 PMEllen Spertus
10/28/2019, 6:52 PMRuckus
10/28/2019, 6:59 PMVoid
value, just like you can't return a Nothing
value in Kotlin (there is no instance of Void
). In order to get this to work, you either need to diverge (not return like your always fail example) or change your return type (you can use Void?
to fit better into the Java world, or if it makes more sense you can change to extend Task<Unit>
and use @James's code.Casey Brooks
10/28/2019, 7:06 PMVoid
has a private constructor, so it is impossible to actually get an instance of Void
. Any method contract that requires you to return Void
is implicitly requesting you return null
instead. I think having your Kotlin method have a return type of Void?
and returning null on the success
branch is the way to go.Ellen Spertus
10/28/2019, 7:26 PMRuckus
10/28/2019, 7:53 PMStephan Schroeder
10/29/2019, 10:39 AMoverride fun getResult(): Unit {
if (!success) throw RuntimeException()
}
should work and is more idiomatic than Void?.
This playground code overrides Java’s Object’s finalize method which returns void in Java by using Unit and it works fine:
class KotlinObject() : java.lang.Object() {
override fun finalize(): Unit {}
}
https://pl.kotl.in/n_umKF6c8karelpeeters
10/29/2019, 11:42 AMTask<Void>
.Stephan Schroeder
10/29/2019, 3:17 PMTask<Unit>
but it does Task<Void?>
, because technically Void?
is as far from Void
as is Unit
. (What about ’Nothing?which is the same set as 'Void?
??)
I guess that the instance of Task<Void?>
is passed back to Java code? Because otherwise using Task<Unit> is probably the answer. Something similar happens when I want to use the ExecutorService
, which only handles `Callable`s and not `Runable`s. In that case Callable<Unit>
is the way to go.Ruckus
10/29/2019, 3:20 PMtechnicallyWhat? How on Earth did you come to that conclusion?is as far fromVoid?
as isVoid
Unit
Void
has nothing to do with Unit
.Casey Brooks
10/29/2019, 3:21 PMTask<Unit>
must return something, namely Unit.INSTANCE
. Task<Void>
does not make sense, since you cannot get a non-null instance of Void
to return, and thus Task<Void?>
must return nullUnit
is analogous to void
in the sense that it is the default return type, but it is not the same thing as void
. void
has no instance, unit
has an instance and is non-null, and has a different meaning from void
in Kotlin’s null-safe world