How to avoid throwing an exception, when expectation parser fails?
I have a rule "function" > (!x3::lexeme[keyword >> !(x3::alnum | '_')] >> symbol) > ('(' > -lvalue_list > ')') > statements > "end"
to parse code like:
function a() return one end
keyword
s is (zero
, one
, function
, return
, end
etc).
If I feed the parser with function one() return zero end
code, then in function expect_directive::parse
exception thrown from here:
if (!r)
{
boost::throw_exception(
expectation_failure<Iterator>(
first, what(this->subject)));
}
When it happens, I got The program has unexpectedly finished. or Aborted (core dumped) (depending on terminal used).
When debugging the code gdb automatically breaks on closing brace '}' in boost::throw_exception
function with message:
The inferior stopped because it received a signal from the Operating System.
Signal name :
SIGABRT
Signal meaning :
Aborted
When stepping through mentioned function step by step it is seen, that throw enable_current_exception(enable_error_info(e));
line is the last line executed before signal emitting. Why there is no stack unwinding for exception handler searching? Why abort instantly raised (looks like boost::throw_exception
have noexcept
specifier)?
I have embraced into try { ... } catch (x3::expectation_failure< input_iterator_type > const & ef) { ... }
x3::phrase_parse
function call. x3::expectation_failure< input_iterator_type >
is exactly the expection thrown from boost::throw_exception
. All it does not matter.
Is there a way to completely avoid x3::expectation_failure
exception in Boost.Spirit X3, but still interrupt parsing of code overall and make x3::phrase_parse
to return false
on expectation failure?
My suspicions are next:
Due to conventional return value of parse()
member function of all parsers (as concept in X3) is bool
, I suspect there are only two ways to report about failure: exception xor return code (which can be only true
or false
, and true
already occupied for Parse successful result reporting). It is inherent for recursive descending parsers implementation in C++. But if we change result type of parse
from bool
to something more wide, we can distinct reporting hard or soft errors (or something else) during parse in more flexible way — by means of different values of return code.