The Kotlin standard library has a neat function require which is something like a runtime assert:
#kotlin.internal.InlineOnly
public inline fun require(value: Boolean, lazyMessage: () -> Any): Unit {
contract {
returns() implies value
}
if (!value) {
val message = lazyMessage()
throw IllegalArgumentException(message.toString())
}
}
When I am debugging, I would like to be able to set a breakpoint in this function, just before the exception is thrown. Like this, I would have the entire stacktrace and local variables visible in the debugger once a requirement is broken. However, this doesn't seem to work:
At first I thought that this is because require is an inline function. I made an experiment with one of my inline functions and the debugger halts as expected.
As a workaround I tried to set the debugger to break on exceptions, but the framework I am working with (Spring) throws a barrage of exceptions on each application start, making it extremely tedious to ignore the irrelevant exceptions.
I would like to know how to make it work, but I am also interested about the why of "it doesn't work".
It's currently not possible to set breakpoints in Kotlin for functions marked with a InlineOnly annotation, and require is one of such functions. Inline functions marked with this annotation don't provide additional debug information in order to save a line from the call site untouched in stack-traces, but it also ruins setting breakpoints inside (https://youtrack.jetbrains.com/issue/KT-24306).
You have spotted one workaround - using exception breakpoints (https://www.jetbrains.com/help/idea/creating-exception-breakpoints.html). IllegalArgumentException would be the best class in this case.
If there're calls in your code that don't work, they might be replaced to custom function as another workaround.
(The answer was updated. The previous version erroneously claimed that breakpoints in require might work for some calls.)
Related
Is there any way to catch unhandled exceptions in compile time in Intellij IDE (or some other way ?)
fun main() {
val list = listOf(1,2)
println(list.first())
}
As you can see list.first() throws an exception (if the list is empty), but I don't get any warning in the IDE to handle it properly. I already tried Csense plugin but unfortunately no luck. I'm not sure how much work it takes to achieve this stuff, I have looked at Intellij PSI element to know if is there any way to recursively trace the function call and to catch some unhandled exceptions, but it's not straight forward as I thought :)
It would be great if someone share the details if they already achieved this in their kotlin project.
Note:
The reason I asked this question is that I'm working on a project which uses kotlin arrow lib to make the code more functional style. So they use Either to handle errors explicitly instead of try/catch.
Using spring boot webflux, I'm trying Blockhound for a very simple blocking call, but it doesn't seem to be detecting it.
<dependency>
<groupId>io.projectreactor.tools</groupId>
<artifactId>blockhound</artifactId>
<version>1.0.6.RELEASE</version>
</dependency>
in main method:
public static void main(String[] args) {
BlockHound.install();
SpringApplication.run(MyApplication.class, args);
}
My blocking endpoint:
#GetMapping("/block")
public Mono<String> block() {
String a = Mono.just("block").block();
return Mono.just(a);
}
Any idea?
EDIT:
When I use UUID.randomUUID() in my endpoint, I get the error related to a blocking FileInputStream#readBytes used by randomUUID().
So I suppose My install is good
Nothing is wrong here, you've just hit a corner case.
Mono.just() is a rather special kind of Mono in more ways than one (which is why I despair at its use in so many simple "getting started" style examples, but I digress) - since you're literally just wrapping a value inside a dummy publisher, it never needs to block in order to return its value, even if you call the block method. The method name might imply you're blocking, but you can trivially verify from the source code that it just returns a value. There's therefore no blocking operation occurring, and so nothing for Blockhound to complain about.
If you were to add another operator in the mix, even if it has no real-world effect:
String a = Mono.just("block").cache().block();
...then you'll see Blockhound start complaining, as you're no longer directly using the special case of MonoJust.
Blockhound is doing exactly what it should here, the issue is that you're (very understandably) expecting something to block which doesn't.
My question is rather theoretical.
I am quite new to kotlin (only passed the tutorial, didn't write any real code).
Reading through the language reference I find myself confused about the fact that "suspend" is a keyword, yet I can't find anything like "launch" in the list of keywords. That makes me think that there is some asymmetry - the "suspend" is a compiler feature, yet "launch" is a library function. Is my understanding correct? If so - wouldn't it have been better to implement both as library features or both as compiler features?
I always thought that you can always write your own standard library using the available language features, but I still can't see if this really applies to this case.
TL;DR: Can I start a coroutine using pure kotlin, without importing any libraries whatsoever (however ugly that would be)?
The suspend marker adds a hidden continuation parameter to the function signature and completely changes the implementation bytecode. Suspension points don't boil down to helper function calls, they turn your linear program code into a state machine, the state being kept in the continuation object. The resulting bytecode isn't even representable as Java program code.
As opposed to that, launch is just regular library code that builds upon the suspend/resume primitive.
#Alexey Soshin's isn't quite correct.
You can use coroutines w/o the library, and it's pretty easy. Here is a about the simplest suspending coroutine example that has 0 dependency on the coroutine library.
import kotlin.coroutines.*
fun main() {
lateinit var context: Continuation<Unit>
suspend {
val extra="extra"
println("before suspend $extra")
suspendCoroutine<Unit> { context = it }
println("after suspend $extra")
}.startCoroutine(
object : Continuation<Unit> {
override val context: CoroutineContext = EmptyCoroutineContext
// called when a coroutine ends. do nothing.
override fun resumeWith(result: Result<Unit>) {
result.onFailure { ex : Throwable -> throw ex }
}
}
)
println("kick it")
context.resume(Unit)
}
This runs fine on the play.kotlinlang.org site.
As you can see from this code, any lambda decorated with suspend has the startCourtine() on it.
In fact, I think the SequenceBuilder() from the standard collection classes uses a simple coroutine like this to generate the sequence, with no dependency on the coroutine library.
The compiler is doing the heavy lifting on the coroutines, splitting the code into different "methods" at each possible suspending point. Look at the java code for this, and you'll see it's "split" into a switch statement. one case before the suspend, and another after.
The library does a ton of nice stuff for you..... and it's likely you'll almost always use it (cuz why not?) but you don't actually need it.
Can I start a coroutine using pure kotlin, without importing any libraries whatsoever (however ugly that would be)?
No. All coroutine generators are inside kotlinx.coroutines library, so you'll need at least that. Now, very theoretically, you could reimplement this functionality yourself. But probably you shouldn't.
How this can be done is a bit too long for a StackOverflow answer, but try invoking method of this Kotlin class from Java:
class AsyncWorks {
suspend fun print() {
println("Hello")
}
}
You'll see that although Kotlin method has no arguments, in Java it requires Continuation<? super Unit>. This is what suspend keyword does. It adds Continuation<T> as the last argument of our function.
wouldn't it have been better to implement both as library features or
both as compiler features?
Ideally, you'd want everything to be a "library feature", since it's easier to evolve. Removing a keyword from a language is very hard. In theory, having suspend as a keyword could be avoided. Quasar, being a framework, uses annotations instead. Go programming language, on the other hand, assumes all functions are suspendable. All those approaches have their advantages and disadvantages.
Kotlin decided to be pragmatic, and add suspend keyword, leaving the decision on the developers. If you're interested in the topic, I highly recommend this talk by Roman Elizarov, author of Kotlin coroutines, that explains their decissions: https://www.youtube.com/watch?v=Mj5P47F6nJg
Answering my own question here.
After a year of Kotlin I tend to think that this IS indeed possible.
The suspend language feature creates an extra class and instantiates it every time your suspend function is called. This class extends ContinuationImpl and stores the progress of your coroutine - to which point it was able to execute so far.
Therefore one will need to write a custom dispatcher that would be able to manage the queue of the continuation objects to decide which one has to run now and a launch function that would take the newly created continuation object and pass it over to the dispatcher.
Now, this is still an asymmetry - the ContinuationImpl lives in kotlin.coroutines.jvm.internal so the compiler assumes this package exists. If one really wants to drop the standard library altogether - he'll need to implement that package to be able use the suspend keyword.
I'm not a kotlin expert though, so I might be wrong.
Because coroutines are valid for use cases that don't support launch. Because suspend requires some specific support from the compiler and launch doesn't if you already have suspend. Because structured concurrency is a library framework on top of the language feature, and launch is a part of that specific framework, that makes specific choices on top of what the language requires.
Starting a coroutine without any libraries can be done with startCoroutine. kotlin.coroutines is part of Kotlin, not a library.
Intellij has an inspection (i.e. lint check) that tells you functions that return Deferred should be named something ending in Async.
Naming conventions like these make sense to me in dynamically typed languages. But Kotlin has such a nice type-checker and ecosystem of tooling, so why rely on the convention?
Especially because Kotlin coroutines bake structured concurrency in, the function will probably also take a CoroutineScope parameter, which would serve the same visual cue at the call site:
suspend fun doStuff() = coroutineScope {
doStuffAsync(this /* CoroutineScope */).await()
//...
}
As a side note, I understand the inspection's message that you'd rarely want a function that returns a Deferred instead of a suspend function. That's not my question. My question assumes that you know what you're doing and you want a Deferred.
To begin with, a function should almost never return a Deferred that comes from an async block. It is up to the caller to wrap some unit of work into an async while doing other work in the foreground, then await on the async result before returning, and wrap all that code in a coroutineScope.
The intended source of Deferred instances is the adaptation layer between Kotlin coroutines and 3rd-party async APIs. For such calls it does make sense to put Async in the name and even some Java APIs follow this convention. For example, you may have a
fun fetchOrder(id: String): Deferred<Order>
and use it as
val orderCancelled = fetchOrder(orderId).isCancelled
This code is type-safe and type-correct, it doesn't cause any compiler errors. It looks like it's fetching an order from a remote system and then checking the order status (whether it's cancelled), but what it's actually doing is getting a Deferred<Order> and checking whether the Deferred is cancelled. Because your function name is missing Async, this kind of error is hard to spot.
Yes, you can also request the IDE to give you the return type, but it may take a while before you even suspect what's going on.
Deferred doesn't return the actual value but is "a light-weight non-blocking future that represents a promise to provide a result later".
As you cannot see this from method name, "we name such functions with the "...Async" suffix to highlight the fact that they only start asynchronous computation and one needs to use the resulting deferred value to get the result".
So the reader of your code can instantly see that your method is not returning the actual value but additionally has to call await() on it.
To your second point about the suspend function:
Usually it's other way round, the xyzAsync() function calls the suspend xyz() function.
As functions returning Deferred can be called from anywhere, not only from suspend functions.
I have a jenkins.gdsl file defining some bindings I'm using in my Groovy script. In addition, I'd like to use the #TypeChecked annotation on my methods to get some guarantees about built code.
My jenkins.gdsl file looks like:
contributor(context(scope: scriptScope())) {
// some definitions
}
And then my script.groovy looks like:
#TypeChecked(extensions='jenkins.gdsl')
void doStuff() {
// ...
}
IntelliJ IDEA autocomplete works, but when building my project I get an error in my jenkins.gdsl file:
Error:Groovyc: groovy.lang.MissingMethodException: No signature of method: org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport.scriptScope() is applicable for argument types: () values: []
Removing (extensions='jenkins.gdsl') gets rid of this error, but then I lose my GDSL definitions when building, so that's a no-go.
It feels like the solution would involve bringing in IntelliJ's standardDsls. I am not at all sure how to do this, or whether it is in fact the correct approach.
#TypeChecked is a Groovy compiler annotation that can run some code during compilation.
But gdsl is an IntelliJ IDEA-specific script that's used only by the IDE to provide some completion and other coding assistance. It doesn't have anything in common with the compiler, and neither of those know anything of each other. So you can remove the extensions value, as it won't provide any typechecking during compilation.