https://kotlinlang.org logo
#ktor
Title
# ktor
j

JoakimForslund

02/24/2020, 12:25 PM
I'm not sure if this is my own implementation or not, but i'm having a really weird experience using latest ktor 1.3.0.
Copy code
var result: T? = null
        try {
            println("FFFFFFFfffff - 2")
            result = httpClient?.request(httpRequestBuilder)
        } catch (e: Exception) {
            println("FFFFFFFfffff - 3: ${e.cause} -> ${e.message}")
            throw e.cause!!
        } finally {
            println("FFFFFFFfffff - 4: ${result}")
            return result
        }
Essentially the result ends up with null, which is not weird because it is initially set as such, however the httpClient?.request does not throw an error and the result is still null The httpClient is initialized, and the engine is also initialized. I'm confused as to why
r

ribesg

02/24/2020, 12:56 PM
Your code is very weird. Remove that
finally
block
A
finally
block is executed all the time, even after the
catch
block has been run. So here you’re both throwing an error THEN returning? I don’t know. It looks weird to me
j

JoakimForslund

02/24/2020, 12:58 PM
It should return at all times
r

ribesg

02/24/2020, 12:59 PM
You can’t both throw and return.
j

JoakimForslund

02/24/2020, 12:59 PM
Are you saying that the final block is interrupting the catch from triggering?
r

ribesg

02/24/2020, 12:59 PM
I’m saying it’s being run after the catch
I don’t know how that’s supposed to work
I didn’t expect that to compile actually
Remove your finally block. That’s just code you want to run after the
try-catch
j

JoakimForslund

02/24/2020, 1:01 PM
Yeah ok thats probably legit, but it does not really solve the problem at hand
r

ribesg

02/24/2020, 1:02 PM
You should only use
finally
when you want to run code after a try-catch even if it catches, for cleanup or potentially logging, but you should never need to return
j

JoakimForslund

02/24/2020, 1:03 PM
Yeah whatever, it still does not handle the issue at hand
r

ribesg

02/24/2020, 1:03 PM
Add
println(httpClient)
before
result = …
j

JoakimForslund

02/24/2020, 1:04 PM
Yeah as said, they are both initialized
r

ribesg

02/24/2020, 1:04 PM
Try to catch
Throwable
instead of
Exception
maybe
j

JoakimForslund

02/24/2020, 1:05 PM
I'll give that a go
r

ribesg

02/24/2020, 1:05 PM
Maybe
.request(…)
returns
null
but that would be weird
Depends what serializer you use maybe
j

JoakimForslund

02/24/2020, 1:07 PM
Yeah so thats my main point here,
request(..)
is for all I can see returning null. This with the latest
KotlinxSerializer
which does specify that you no longer need to register specific serializers
And afaik this is the only thing that changed between 1.3.0 and 1.3.3 in my implementation
@ribesg Changing to Throwable did allow me to recieve the error
Thanks a lot
👍 1
l

Leon K

02/24/2020, 1:34 PM
still, the code is super weird. what you most likely want is something like this:
Copy code
val result: T? = httpClient?.use { client -> 
  try { 
    client.request(httpRequestBuilder)
  } catch(e: Throwable) {
    println(...)
    throw e.cause!! // <- this is weird too, but idk
  }
}
there seems no need to have result be uninitialized first, or to have the finally part
I'd also recommend you to try to avoid needing to catch
Throwable
as that will contain a lot of things you most likely don't want to catch there. Even if it is just for intermediate logging,... do that logging higher up
j

JoakimForslund

02/24/2020, 1:35 PM
Thanks Leon, both your inputs are valid regarding the final block. However the catch is needed for internal logging
l

Leon K

02/24/2020, 1:37 PM
well then, keep the catch ;D But I'd strongly recommend using the try, etc as an expression to directly assign the value to the result instead of needing to reasign it (making it `var`for no good reason). Also, depending on if you use the same client afterwards, please remember to close it / use
.use
if not