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

Options for more robust error handling #60

Open
tiffany1618 opened this issue Feb 1, 2021 · 0 comments
Open

Options for more robust error handling #60

tiffany1618 opened this issue Feb 1, 2021 · 0 comments
Labels
input wanted Issues whose implementations are open for discussion and suggestions

Comments

@tiffany1618
Copy link
Member

There are several ways to handle errors in C++, such as:

1. (current solution) Error code checking

This is a simple way of handling errors, but it requires a lot of tedious if/else statements that can affect readability. If we were to stick with this method, we would need to add proper error propagation.

2. C++ Exceptions

This is the "idiomatic" way of handling errors in C++ (see a tutorial on how to use them here) which has no overhead if no exceptions are thrown (as opposed to error code checking, where a check must occur whether or not an error is present). This would also be pretty simple to implement, but there may be a better way...

3. C++ implementation of Rust's Result<T, E> type

The Rust programming language implements error handling via its Result<T, E> type, which is a type that contains either a value of type T, or an error describing what went wrong. There are also a bunch of methods on this type that make error checking and error propagation pretty painless. I've found this type of error handling to be very clean and readable, but unfortunately, C++ doesn't have a standard implementation of this type. There is the builtin-in std::optional<T> type (documentation here) that contains either a value of type T or is null, but this would have to be used in conjunction with another error handling scheme since it can't convey an error by itself. If we wanted to use this type of error handling, we could also implement a C++ Result-like type on our own, or we could use someone else's implementation. I found one here that also provides some extra functions to make things easier.

These are all valid solutions to error handling, and I'm curious what you guys think. Any input is very much wanted!

@tiffany1618 tiffany1618 added the input wanted Issues whose implementations are open for discussion and suggestions label Feb 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
input wanted Issues whose implementations are open for discussion and suggestions
Projects
None yet
Development

No branches or pull requests

1 participant