Close Channel on Error #183
Conversation
Fixes #182.
Sources/HttpPipeline/NIO.swift
Outdated
| @@ -107,6 +107,10 @@ private final class Handler: ChannelInboundHandler { | |||
| } | |||
| } | |||
| } | |||
|
|
|||
| func errorCaught(ctx: ChannelHandlerContext, error: Error) { | |||
| _ = ctx.close() | |||
There was a problem hiding this comment.
if you use ctx.close(promise: nil) you can save one allocation for when you don't care about the result anyway (I realise my example code didn't do that ;) )
There was a problem hiding this comment.
Good to know, thanks! We've only started to dig deeper into NIO from our current lightweight wrapper. We've got a branch going that redefines middleware as (Conn<I, A>) -> EventLoopFuture<Conn<J, B>> everywhere instead of our current stack built on IO: https://github.com/pointfreeco/swift-web/compare/nio-conn
Haven't been able to fully flesh it out yet, though!
| headers: .init([("location", self.baseUrl.absoluteString)]) | ||
| ) | ||
| ), | ||
| promise: nil |
There was a problem hiding this comment.
@weissi Is it safe to assume that we should favor these promise: nil overloads over _ = wherever we're not then-chaining?
There was a problem hiding this comment.
yes, there's no difference apart from allocating the promise/future that you'd then throw away with _ = . Therefore if you don't need the result, just passing promise: nil is just a bit cheaper. Here's the NIO code:
stephencelis
force-pushed
the
close-on-error
branch
from
a236ab6
to
18a4fb7
Compare
Fixes #182.
We probably want to add some kind of logging, too.