Skip to content
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

Improve error handling in libflate #23399

Merged
merged 1 commit into from
Mar 17, 2015
Merged

Conversation

tbu-
Copy link
Contributor

@tbu- tbu- commented Mar 15, 2015

This removes the error case of the compression functions, the only errors that
can occur are incorrect parameters or an out-of-memory condition, both of which
are handled with panics in Rust.

Also introduces an extensible Error type instead of returning an Option.
The type implements a destructor so you can't destructure it.

@rust-highfive
Copy link
Collaborator

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

@tbu- tbu- force-pushed the pr_libflate_error branch from 0d4c671 to ef50ac5 Compare March 15, 2015 23:33
}
}

impl Drop for Error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, what's this for?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just so you can't destructure Error in foreign code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah; I believe the field being private should cover that case adequately?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can still do things like let Error(_) = e, removing the possibility of changing this to a struct or an enum later on (or just about anything else than a tuple struct).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is Error defined as a tuple-struct in the first place? I think this is generally not a good idea (#22045). Implementing a pointless Drop seems like a bad solution.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nikomatsakis I can't think of a better solution than implementing Drop. Making it a struct means it can't be changed to an enum later on, and vice versa. The tuple struct is not special in that regard. The issue you linked to talks about tuple structs with all-pub fields, this one only has a private field.

EDIT: And I'm not sure why "a pointless Drop" is a bad solution, it has no side effects AFAIK except for not being able to implement Copy, but that should probably not be done anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a private library to rustc where we do not need to worry about backwards compatibility. Additionally breaking let Error(_) = foo does not seem to me to warrant an extra blank impl of Drop. Having this extra impl is unfortunate because it is unexpected and especially without a comment it will be difficult for later readers to understand why this is here.

@tbu- tbu- force-pushed the pr_libflate_error branch from ef50ac5 to d6d77a4 Compare March 16, 2015 18:13
This removes the error case of the compression functions, the only errors that
can occur are incorrect parameters or an out-of-memory condition, both of which
are handled with panics in Rust.

Also introduces an extensible `Error` type instead of returning an `Option`.
@tbu- tbu- force-pushed the pr_libflate_error branch from d6d77a4 to 1b894c6 Compare March 16, 2015 18:15
@tbu-
Copy link
Contributor Author

tbu- commented Mar 16, 2015

@huonw Now without the destructor, and as a proper struct.

@huonw
Copy link
Member

huonw commented Mar 17, 2015

@bors r+

@bors
Copy link
Contributor

bors commented Mar 17, 2015

@bors r=huonw 1b894c6

@bors
Copy link
Contributor

bors commented Mar 17, 2015

⌛ Testing commit 1b894c6 with merge 963bac4...

bors added a commit that referenced this pull request Mar 17, 2015
This removes the error case of the compression functions, the only errors that
can occur are incorrect parameters or an out-of-memory condition, both of which
are handled with panics in Rust.

Also introduces an extensible `Error` type instead of returning an `Option`.
The type implements a destructor so you can't destructure it.
Manishearth added a commit to Manishearth/rust that referenced this pull request Mar 17, 2015
 This removes the error case of the compression functions, the only errors that
can occur are incorrect parameters or an out-of-memory condition, both of which
are handled with panics in Rust.

Also introduces an extensible `Error` type instead of returning an `Option`.
The type implements a destructor so you can't destructure it.
@bors
Copy link
Contributor

bors commented Mar 17, 2015

💔 Test failed - auto-mac-64-opt

@tbu-
Copy link
Contributor Author

tbu- commented Mar 17, 2015

That failure doesn't look related to this pull request.

@Manishearth
Copy link
Member

Passed in the rollup, seems like an intermittent.

@Manishearth
Copy link
Member

Filed #23440

@bors bors merged commit 1b894c6 into rust-lang:master Mar 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants