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

Updating the exception class #639

Closed
jonathf opened this issue Jan 1, 2022 · 2 comments
Closed

Updating the exception class #639

jonathf opened this issue Jan 1, 2022 · 2 comments

Comments

@jonathf
Copy link
Collaborator

jonathf commented Jan 1, 2022

Topic for discussion.

How do we feel about refactoring the current implementation of Exception?

  1. Could we add a what method to the exception? It is required if pybind11 is to retrieve the underlying error message. This is as far as I can tell also idiomatic C++.

  2. How do we feel about adding three subclasses: InputException InternalException RoutingExeption which hardcodes ERROR in their constructors? (Or perhaps deprecate the ERROR enum if it is no longer needed.) We then use the specific exceptions around in the codebase. It also works better on the Python side of things where the visual error representation is quite important.

  3. An idea BTW that also is perhaps worth considering: Adding a unsigned exit_code attribute to the exception directly.
    This way you can do:

    } catch (const vroom::Exception& e) {
         std::cerr << "[Error] " << e.message << std::endl;
         vroom::io::write_to_json({e.error_code, e.message},
                             false,
                             cl_args.output_file);
    

    and you can replace:

    //auto error_code = vroom::utils::get_code(vroom::ERROR::ROUTING);
    auto error_code = vroom::RoutingException().error_code

    get_code then becomes obsolete and can be removed.

@jcoupey
Copy link
Collaborator

jcoupey commented Jan 4, 2022

Thanks for the suggestion. It would totally make sense to have dedicated subclasses for different kind of exceptions. I have the same feeling that in this case we could remove the ERROR enum altogether. Then removing the need for an external function to retrieve the code would also be much clearer.

@jonathf jonathf mentioned this issue Jan 4, 2022
3 tasks
@jcoupey jcoupey added this to the v1.12.0 milestone Jan 6, 2022
@jcoupey
Copy link
Collaborator

jcoupey commented Jan 13, 2022

Done in #641. Thanks @jonathf the exception logic is clearer and easier now!

@jcoupey jcoupey closed this as completed Jan 13, 2022
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

2 participants