Error management

36 views
Skip to first unread message

fabien...@imt-atlantique.fr

unread,
Mar 8, 2019, 11:23:24 AM3/8/19
to SableCC
Hi again,
Another question we recently faced was with the parse error management. In all the description of sablecc, I read that it support error management but I have found no documentation on how to do it... We would like to support a better user experience than just stopping the parsing and reporting an error. Typically we would like to try to parse all the file even if some parts contain errors. Is it possible in some way?

Fabien


Etienne Gagnon

unread,
Mar 8, 2019, 11:37:38 AM3/8/19
to sab...@googlegroups.com
Hi Fabien,

Trying to parse past a syntax error is a form of black magic; it
requires trying to get into the brain of the user and guess what the
user wanted.

It only takes a fraction of a second to parse a file. Back, decades ago,
people had to punch cards to feed their programs into a computer. I can
easily understand how they needed get a list of errors, even if 90% of
errors were false positives caused by earlier errors, due to the time it
took to punch a modified program.

Today, in our immediate-feedback world, pointing to the first error and
asking the user to fix it, without having to go through a long list of
false positives, seems like a sensible and modern approach.

I have no plan to add support for parsing past a syntax error to SableCC.

Cheers,

Etienne

Etienne Gagnon, Ph.D.
http://sablecc.org

fabien...@imt-atlantique.fr

unread,
Mar 8, 2019, 11:54:42 AM3/8/19
to SableCC


Le vendredi 8 mars 2019 17:37:38 UTC+1, Etienne Gagnon a écrit :
Hi Fabien,

Trying to parse past a syntax error is a form of black magic; it
requires trying to get into the brain of the user and guess what the
user wanted.

It only takes a fraction of a second to parse a file. Back, decades ago,
people had to punch cards to feed their programs into a computer. I can
easily understand how they needed get a list of errors, even if 90% of
errors were false positives caused by earlier errors, due to the time it
took to punch a modified program.

Today, in our immediate-feedback world, pointing to the first error and
asking the user to fix it, without having to go through a long list of
false positives, seems like a sensible and modern approach.
Ok, but in our case the language is very structured and it would be easy to close the current structure on error and continue parsing on the next one...
 
One of the usage we would have, would be for interactive editors that keep parsing behind your back and give feedback on the syntactic correctness (such as the Java parser of eclipse used by the Java editor).
 
I have no plan to add support for parsing past a syntax error to SableCC.
Ok, as I read in some place that you had this support, I was willing to try it but if it does not exist...
 
Fabien

Etienne Gagnon

unread,
Mar 8, 2019, 12:10:45 PM3/8/19
to sab...@googlegroups.com
Hi Fabien,

If the grammar is really well structure, it's sometimes possible to
simply include erroneous constructs within the grammar, as long as they
don't cause conflicts. That's the most robust approach to handle known
errors.

The general problem is that there's an infinite number of erroneous
constructs. It's simply impossible for a parser to know which valid
construct was desired by the user.

Even programs which are free from parsing errors contain errors, because
the users didn't write what he really wanted, or maybe he was confused
about the outcome of his code, or maybe the user simply forgot to
declare a variable.

Anyway, the idea is that the number of possible mistakes is infinite.
Doing "error recovery" while minimizing false positives is very
difficult to achieve, and often useless.

If I wanted to give more flexibility to users of a language, I would
just try to design a lighter and more flexible syntax, instead of trying
to rely on unreliable error recovery.

Etienne Gagnon

unread,
Mar 8, 2019, 12:29:01 PM3/8/19
to sab...@googlegroups.com
The biggest problem of SableCC 3.7, for using it with an editor, is that
it only reports the parsing error and doesn't provide any information
about the parts it already succeeded to parse.

What I intend to add in future versions is to provide a partial syntax
tree in case of parsing error. This would allow an editor to indent the
text up to the first parsing error.
Reply all
Reply to author
Forward
0 new messages