Exception in Route.handle is handled silently about ktor HOT 12 CLOSED

CallLogger currently does not work as it should: #50

On top of that, swallowing exceptions silently by default is a very bad practice, resulting in an incredibly hostile learning curve.

Perhaps tutorial-mode setups like embeddedJettyServer(routing = ...).start() should have it baked in by default, with logging to stdout/stderr preconfigured?

from ktor.

Just a matter of notice, we have a test for this case (throwing inside respondWrite), but it didn't fail because in test environment it was not "asynchronous enough". Need proper integration test…

from ktor.

I verified this case in our new coroutine-based implementation and everything is good (given CallLogging is installed)

from ktor.

You can install CallLogger feature to see exceptions

class Blocking(environment: ApplicationEnvironment) : Application(environment) {
    init {
        install(CallLogging)

        routing {

from ktor.

It's not that we swallow exceptions by default, as you picture it. Highly async code is hard to make bullet-proof, but we are moving there. Missing a catch-and-marshall in one place can easily look like swallowing, but it's actually may be accidentally ignored in CompletableFuture callback or something.

from ktor.

I think my confusion about this is now a little bit clearer. I did not know we had calllogging in our setup so I thought it was the default behaviour. In any case exceptions are actually being swallowed here. If you add install(CallLogging) it will only print one stack trace to the console. The first in route /exception is not being reported.

from ktor.

@spand I've reproduced the issue, but I see it not reported for exception2. Exception for exception route is reported if CallLogging is installed.

from ktor.

So indeed, it's not a swallowed exception. It's a double-exception error. It hits CallLogging interceptor with correct exception on a failing path. But then CallLogging tries to get method from an HttpRequest to show which request failed, and fails to get it, because request is already closed.

Thanks for noticing, we will fix it.

from ktor.

Oh, my mistake again. Glad to be of service in any case ;-)

from ktor.

I have a feeling the async core of ktor is going to be a nightmare to maintain, so it's unlikely for ktor to be production-ready anytime soon :( shame, since Kara development appears to be mostly dormant and Wasabi is also quite unstable (Gradle builds, ugh).

from ktor.

Any progress on this ?

from ktor.

Debug note:
This is caused by https://github.com/Kotlin/ktor/blob/7f72bd3fcf7d53d289a3252dcac39a5300db413a/ktor-hosts/ktor-hosts-common/src/org/jetbrains/ktor/host/BaseApplicationCall.kt#L115-L115

closeAtEnd in sendAsyncChannel installs failure handler to properly close a call in case of failure or success, and it executes before CallLogging have a chance to report an exception. Then call.request.logInfo() fails because underlying request was already cleaned up.

from ktor.