-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The error types should be refactored #20
Comments
@nox let's do these improvements |
As a first step, I want to change: pub enum HandshakeError<S> {
/// Setup failed.
SetupFailure(ErrorStack),
/// The handshake failed.
Failure(MidHandshakeSslStream<S>),
/// The handshake encountered a `WouldBlock` error midway through.
///
/// This error will never be returned for blocking streams.
WouldBlock(MidHandshakeSslStream<S>),
}
pub struct MidHandshakeSslStream<S> {
stream: SslStream<S>,
error: Error,
} to pub enum HandshakeResult<S> {
Done(SslStream<S>),
WouldBlock(MidHandshakeSslStream<S>),
Failed(StreamError<S>),
}
pub struct StreamError<S> {
stream: S,
error: Error,
}
pub struct MidHandshakeSslStream<S> {
stream: SslStream<S>,
} We would return Another way I thought of is: pub enum HandshakeStream<S> {
Done(SslStream<S>),
Mid(MidHandshakeSslStream<S>),
}
pub struct StreamError<S> {
stream: S,
error: Error,
} And we would just return |
Actually the second way with |
For now, it looks like this: master...nox:errors |
Actually, I realise now that both ways are bad, because in the end, the implementations of |
I was staring at those two snippets thinking this would hinder my plan of making everything be Line 3131 in 2667b0f
Line 3147 in 2667b0f
(Note for some reason that both check Apparently we specifically check for this error code with no explicit I/O error because After reading the docs a bit more, this seems not necessary because we set boring/boring/src/ssl/connector.rs Lines 37 to 38 in 0c9166d
So AFAIK there is no need to distinguish "BoringSSL returned |
Yeah, |
@nox did you ever finish working on this? Or do you have a WIP branch I could adapt? Would love to improve the error API. |
#142 removes |
I have many issues with the various
Error
types we define and howHttpsConnector
ultimately just usesBoxError
for itsService<Uri>
error type, I'll try to summarize them here.First, the
BoxError
, this makes it impossible to consume any more specific error type, as downcasting with theError
trait is always by reference.Second, I keep confusing myself with
boring::Error
andboring::ssl::Error
.Third, the
boring::ssl::HandshakeError
is not fun to use for multiple reasons:Failure
andWouldBlock
);MidHandshakeSslStream<S>
even in theFailure
variant, even though you are obviously not supposed to do anything anymore with that stream given the handshake failed;MidHandshakeSslStream<S>
struct to keep around the error that interrupted the handshake, as that was expected and you just want to resume it;SetupFailure
which feels out of place to me, shouldn't setup errors be completely contained in builders etc?Fourth,
tokio_boring::HandshakeError
is as useful asBoxError
given it doesn't let us access theboring::ssl::HandshakeError
it wraps directly, so that's one more layer of hoops to go through to find, say, I/O errors.Fifth, even if
tokio_boring::HandshakeError
let us access its innerboring::ssl::HandshakeError
, that would still be a bit of a bother to use, as we knowtokio_boring
would never return aWouldBlock
error but we would still need an arm for that in our code.The text was updated successfully, but these errors were encountered: