I'm not sure if this is my own implementation or not, but i'm having a really weird experience using...

# ktor

[JoakimForslund]

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.

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

[ribesg]

Your code is very weird. Remove that finally block

[ribesg]

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

[JoakimForslund]

It should return at all times

[ribesg]

You can’t both throw and return.

[JoakimForslund]

Are you saying that the final block is interrupting the catch from triggering?

[ribesg]

I’m saying it’s being run after the catch

[ribesg]

I don’t know how that’s supposed to work

[ribesg]

I didn’t expect that to compile actually

[ribesg]

Remove your finally block. That’s just code you want to run after the try-catch

[JoakimForslund]

Yeah ok thats probably legit, but it does not really solve the problem at hand

[ribesg]

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

[JoakimForslund]

Yeah whatever, it still does not handle the issue at hand

[ribesg]

Add println(httpClient) before result = …

[JoakimForslund]

Yeah as said, they are both initialized

[ribesg]

Try to catch Throwable instead of Exception maybe

[JoakimForslund]

I'll give that a go

[ribesg]

Maybe .request(…) returns null but that would be weird

[ribesg]

Depends what serializer you use maybe

[JoakimForslund]

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

[JoakimForslund]

And afaik this is the only thing that changed between 1.3.0 and 1.3.3 in my implementation

[JoakimForslund]

@ribesg Changing to Throwable did allow me to recieve the error

[JoakimForslund]

Thanks a lot

[Leon K]

still, the code is super weird. what you most likely want is something like this:

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

[Leon K]

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

[JoakimForslund]

Thanks Leon, both your inputs are valid regarding the final block. However the catch is needed for internal logging

[Leon K]

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