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

Exceptions #48

Closed
joto opened this issue Dec 4, 2015 · 5 comments
Closed

Exceptions #48

joto opened this issue Dec 4, 2015 · 5 comments
Assignees
Milestone

Comments

@joto
Copy link
Contributor

joto commented Dec 4, 2015

Currently std::runtime_exception is thrown in a few cases. Should we have our own exception type?.

In the case of get<wrong_type>() P0088R0 uses bad_variant_access derived from logic_error for this.

@springmeyer
Copy link
Contributor

👍 to custom exception type if you see a benefit (as long as it inherits from std::exception of course).

@joto
Copy link
Contributor Author

joto commented Dec 4, 2015

A custom exception type would allow a user to differentiate between an exception thrown by our variant type and an exception that is somehow propagated from a type wrapped in the variant. I am not sure this is strictly necessary, but it would be cleaner in any case.
Before I change this: Is there any code checking for this exception somewhere? @artemp ?

@artemp
Copy link
Contributor

artemp commented Dec 4, 2015

@joto - sounds good re: custom exception.
Lets derive it from std::exception so existing code will continue to work or at least it'll be easy to fix.

@joto
Copy link
Contributor Author

joto commented Jan 13, 2016

I have create a new class bad_variant_access now derived from std::runtime_error and use this in the get<T>() functions. This is backwards-compatible. User code using this should switch to the new type and then we can later on switch the parent class to the more correct std::logic_error as in the upcoming standard.

@joto joto added this to the 1.0.0 milestone Jan 13, 2016
@joto joto self-assigned this Jan 13, 2016
@springmeyer springmeyer modified the milestones: 2.0.0, 1.0.0 Jan 28, 2016
@artemp
Copy link
Contributor

artemp commented Jan 6, 2017

closing as this issue moved to #95

@artemp artemp closed this as completed Jan 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants