-
Notifications
You must be signed in to change notification settings - Fork 84
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
Add a location to each of 'NIOHTTP2Errors' #247
Conversation
a513cbe
to
0496587
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
9198cb3
to
d23c0c2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really good, thanks for doing this large chunk of work! I've left some notes in the diff, but nothing substantial.
8506ef8
to
0acd091
Compare
Motivation: Without knowing where an error was thrown it can be unnecessarily difficult to work out the reasons an application ended up in an error state. Modifications: - Add a 'file' string to each of the 'NIOHTTP2Errors' denoting the file and line where an error was created - Add static methods to create errors to 'NIOHTTP2Errors' defaulting file and line, this is unfortunately necessary as defaulting file and line in the `init` makes the defaulted and non-defaulted errors indistinguishable, and the compiler will pick the one with fewest defaulted values. - Add equatable conformance manually so as to ignore 'file' - Add backing storage to errors which no longer be stored in an existential container - Add 'CustomStringConvertible' conformance to the errors using backing storage so that the 'file' is actually visible when converting the error - Deprecate the old `init`s - Fix all deprecation warnings Result: - NIOHTTP2Errors carry a 'file' with them indicating where they were created
0acd091
to
3a494d7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one @glbrntt, good work!
Motivation:
Without knowing where an error was thrown it can be unnecessarily
difficult to work out the reasons an application ended up in an error
state.
Modifications:
and line where an error was created
file and line, this is unfortunately necessary as defaulting file and
line in the
init
makes the defaulted and non-defaulted errorsindistinguishable, and the compiler will pick the one with fewest
defaulted values.
container
storage so that the 'file' is actually visible when converting the
error
init
sResult:
created