I just thought that it would be nice if we could g...

# language-proposals

[Marc Knaup]

I just thought that it would be nice if we could get access to the eventual exception in the finally block.
I often log timing, exceptions and cancelations for a block of code. With the current approach I’d have to duplicate logging code in catch clause(s) and at the end of the try block in the success case. I’d also have to use .also { … } in the try block to not change the return value.

It would be much easier if I could something like

val start = TimeSource.Monotonic.markNow()
val x = try {
   lotsOfLogic()
}
finally { e -> // Throwable?
    // complicated logging with or without exception
}

Without:

val start = TimeSource.Monotonic.markNow()
val x = try {
   lotsOfLogic().also {
     // complicated logging without exception
   }
}
// multiple catch clauses would duplicate logging
catch(e: Throwable) {
    // complicated logging with exception
    throw e // rethrow needed
}

[louiscad]

You can make a higher order function do this I think.

[Marc Knaup]

Yeah, but I prefer to avoid higher order functions that take two lambdas. Syntax-wise it just doesn’t feel right when both lambdas tend to get larger.

And would it cause boxing when dealing with primitives?

[Iaroslav Postovalov]

Untitled

Untitled

[louiscad]

@Marc Knaup No boxing if inline.

[Marc Knaup]

@louiscad even with generics?

[Iaroslav Postovalov]

Argument types are primitive, only return type may be boxed

[louiscad]

@Marc Knaup Even with generics yes, you can check usage with Kotlin bytecode (so long as you don't use coroutines in that file)

[Marc Knaup]

As long as you don’t mean the bytecode viewer. According to that one there aren’t any optimizations happening 😅

[louiscad]

I meant the bytecode viewer, but at use site, not declaration site.

[Marc Knaup]

Yes I've tried that in another instance where I've written a generic function to create the hash of multiple values.
I can add as many inlines I want to - it still used plenty of boxing for Int :(

[louiscad]

Makes sense to report it on kotl.in/issue with reproducing snippet?

[Marc Knaup]

I’ve asked in #compiler and it looks like that the Bytecode Viewer is just very unreliable.