Also, because python lacks gotos and switch statements, "exception-oriented" code is a good way to implement efficient finite state machines common in compiler code.
The exceptions seem to be how it signals failure if the token doesn't match, but they aren't being used for unbounded lookahead.
The main downside I see to branching on the next token within the parse_statement function itself is that doing so would split logic between the parse_* functions called by parse_statement (parse_if_statement, parse_while_statement, etc) and the parse_statement function itself.
For example, suppose parse_statement was modified to only calling `parse_if_statement` if the next token was an `if`, thus avoiding the try-except pattern. Then, while parse_statement would be responsible for checking if the next token is `if`, parse_if_statement would be responsible for parsing the `(` token, the expression that follows, the closing `)`, and so on. I figured it was easier to keep the entire identity of an if-statement within the parse_if_statement function itself rather than splitting it between the parse_statement and parse_if_statement functions.
Or you know how to fix it? Then just pull[1] it to 'master' ;-)
https://github.com/ShivamSarodia/ShivyC/blob/master/shivyc/p...
It's been a while since I've had to use the phrase "exception-oriented programming", but it fits that code well. While that might be a useful or even necessary pattern to parse something like C++ which can have almost unbounded ambiguities, AFAIK C can be parsed solely by branching on the next token in the stream except for one tiny case (typedefs).