Skip to content

Allow disabling exception handling #80

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

sloede
Copy link
Contributor

@sloede sloede commented Jun 4, 2018

This PR is an attempt at allowing to use cpptoml with exception handling disabled. All changes are guarded behind the CPPTOML_NO_EXCEPTIONS macro, which by default is undefined. The following changes are included:

  • replace throws by THROW_/THROW2_ macros, which in turn call die(...), which in turn calls std::exit(1)
  • in table::get_as and table::get_qualified_as, the control logic was changed from exceptions to using the contains and contains_qualified methods
  • in parser::parse_int and parser::parse_float, exception handling was disabled completely such that exceptions from std::stoll and std::stod are not caught anymore but directly propagated upwards

If you feel that this is the wrong approach or could be improved somehow, I'd be happy for suggestions.

@skystrife
Copy link
Owner

First, thanks for working on this!

While this certainly allows for compilation without exceptions enabled, I think the more ideal situation would be to specify an alternate API where the errors are propagated up to the caller via some other mechanism so they can then be handled at the call site, rather than aborting the program entirely. I'm imagining something like this:

cpptoml::parse_error error;
auto config = cpptoml::parse_file("config.toml", error);
if (!error)
{
    // use config as usual
}
else
{
    auto why = error.message();
    // do something useful to e.g. alert the user about the parsing error
}

Such a change should be somewhat mechanical. For private methods we can simply modify them to instead use the out-param error method for error reporting instead of throwing. For public methods, we can first modify them to use the out-param error method, and then add a throwing stub method for backwards-compatibility:

T fun(Args... args)
{
    parse_error error;
    auto res = fun(args..., error);
    if (error) throw_parse_error(error.message());
    return res;
}

Does that sound reasonable?

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.

2 participants