Hello everybody. I'm in a weird case. I'm trying t...
# android
c
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
Are you returning from your try or catch blocks?
c
in some lines yes, others no
but none stops at finally
and AS, shows the alert "no executable code" at finally blocks
k
there has to be a little checkmark on the BP when you're running
c
yes
k
unfortunately the debugger has never been top notch
l
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
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
So if you’re returning before finally it will never get executed
l
@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
image.png
this is how it looks
k
have to ask the obvious question... you're sure you built and ran after adding that line?
r
@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
seems pretty intuitive to me 😛
c
Yes, I did @Kris Wong. I'm doing it right now 😛
k
that's quite strange then
c
It just don't stop at the line
k
is that function inlined and empty?
c
no, it is a regular one
k
i'm out of ideas
c
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
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
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
@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
Ya I see the utility. Tbh though I’d prefer something like Go or Swift’s
defer
keyword for that.
l
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>