https://kotlinlang.org logo
#android
Title
# android
c

cucharro

08/19/2019, 3:27 PM
Hello everybody. I'm in a weird case. I'm trying to debug some code but my debugger never stops at finally blocks, does anyone knows why? To me the finally block should be reached all the time, right?
r

Robert Menke

08/19/2019, 3:31 PM
Are you returning from your try or catch blocks?
c

cucharro

08/19/2019, 3:32 PM
in some lines yes, others no
but none stops at finally
and AS, shows the alert "no executable code" at finally blocks
k

Kris Wong

08/19/2019, 3:33 PM
there has to be a little checkmark on the BP when you're running
c

cucharro

08/19/2019, 3:34 PM
yes
k

Kris Wong

08/19/2019, 3:34 PM
unfortunately the debugger has never been top notch
l

louiscad

08/19/2019, 3:34 PM
Do you have actual code in that
finally
block? You'll need to put the breakpoint on a line having this actual code, I don't think lines where the
finally
keyword is the only code can have breakpoints (the IDE shows you a checkmark or a stop mark to tell you about it once the class is loaded)
👍 1
c

cucharro

08/19/2019, 3:34 PM
I tried that, but when running code that stop (circle with cross line) is shown
yes there is code, I'll share a print
r

Robert Menke

08/19/2019, 3:35 PM
So if you’re returning before finally it will never get executed
l

louiscad

08/19/2019, 3:37 PM
@Robert Menke Wrong:
finally
is always executed after the
return
expression, just before the value is actually returned.
Unless you didn't enter the corresponding
try
block of course.
c

cucharro

08/19/2019, 3:39 PM
image.png
this is how it looks
k

Kris Wong

08/19/2019, 3:40 PM
have to ask the obvious question... you're sure you built and ran after adding that line?
r

Robert Menke

08/19/2019, 3:40 PM
@louiscad 🤦‍♂️ Oh man I never use it like that. Just had to try it out in the editor. Kind of unintuitive tbh.
thanks for the correction
k

Kris Wong

08/19/2019, 3:41 PM
seems pretty intuitive to me 😛
c

cucharro

08/19/2019, 3:41 PM
Yes, I did @Kris Wong. I'm doing it right now 😛
k

Kris Wong

08/19/2019, 3:41 PM
that's quite strange then
c

cucharro

08/19/2019, 3:41 PM
It just don't stop at the line
k

Kris Wong

08/19/2019, 3:42 PM
is that function inlined and empty?
c

cucharro

08/19/2019, 3:42 PM
no, it is a regular one
k

Kris Wong

08/19/2019, 3:42 PM
i'm out of ideas
c

cucharro

08/19/2019, 3:42 PM
I'll print a logcat message just to check if the code running. This is first time I'm through that
it's running. Look like it is an AS bug
thank you everybody for the help
l

louiscad

08/19/2019, 3:46 PM
Look in the gutter @cucharro: there's a barred sign meaning it couldn't find the corresponding line of code deployed on the device! You can try running the app again, and make sure you don't edit the code afterwards, as this will otherwise shift the code line numbers and deployed code under debugging would be out of sync with code in IDE, putting in at risk to encounter the same issue again.
👍 1
r

Robert Menke

08/19/2019, 3:48 PM
I mean it doesn’t seem intuitive to me that
finally
intercepts a return in a try block.
Copy code
fun foo(): String {
        try {
            return "hello"
        }
        finally {
            return "world"
        }
    }
but I suppose it makes sense
l

louiscad

08/19/2019, 3:56 PM
@Robert Menke It's very useful to unregister listeners/callbacks with coroutines. Also, almost no one uses the
return
keyword in a
finally
block.
r

Robert Menke

08/19/2019, 3:57 PM
Ya I see the utility. Tbh though I’d prefer something like Go or Swift’s
defer
keyword for that.
l

louiscad

08/19/2019, 3:57 PM
But I just learned thanks to you it works the intuitive way:
finally
wins.
defer
means something entirely different to me
async
from kotlinx.coroutines returns
Deferred<T>