Take the 2-minute tour ×

I want to parse Java/COBOL/VB etc code to collect information like variable name, method etc

I am using javacc grammar but my problem is that if any exception comes then parser fails

Apart from JAVA, I use javacc grammar for COBOL, VB etc

I do not want that parser should fail so i am trying to read java code line by line to get desired result.

Any better way to do the parsing without throwing exception?

Thanks in advance.

share|improve this question
What do you mean by "an exception comes"? Do you also want to be able to gracefully handle invalid Java code and parse as much of the rest as possible? –  Thilo Nov 7 '11 at 6:51
@Rahul Can you give us an example of the code that throws the exception? Or what type of exception is thrown? –  phuibers Nov 7 '11 at 6:55
Reading the source code line-by-line will work only if you have the very simplest of tasks, and you don't care much if it does it wrong. For most real langauges, if you want to collect accurate data, there are no good solutions that don't involve a real parser for the langauge. –  Ira Baxter Nov 7 '11 at 8:10

4 Answers 4

Parsers (and therefore the machinery provided by parser generators) must have some mean to handle invalid source files. Thus each parser (and parser generator) has chosen some method to manage syntax errors.

An easy solution provided by most is simply to throw an exception when such an error is encounterd. The user code invoking the parser has to catch this exception and live with an aborted parse. A more sophisticated solution to have the parser report a syntax error, but recover from the error and continue parsing; any such recovery must handle AST building with some kind of marker on the nodes at the point of error if you also hope to get a usable tree. Most parser generators will offer some kind of syntax recovery, but leave you on your own to handle AST building the face of such errors. Such parser recovery logic is relatively hard to build, and you likely can't do it yourself without becoming an expert in parser error recovery, and making custom changes to the particular parser generators support code.

I'm not specifically familiar with JavaCC (or most of the other parser generators out there), so I don't know if it does this. Obviously, check the docs. If the error handling support you want isn't there, move on to another generator that has it.

I suspect your real problem will actually be getting grammars appropriate for your task. Nobody has "Java" or "COBOL"; they have a specific dialect, e.g., Java 1.5 or IBM Enterprise COBOL or VB6. These are more different from the imagined base language that you expect based on my long experience. You can hope that such grammars as you can obtain will work (including error recovery) to enable you to parse the various dialects of each ins spite of such differences, but generally you'll get large numbers of errors from code in one dialect that doesn't match the grammer you want. (What will you do with the card numbers out past column 72, in your IBM Enterprise COBOL code that has EBCDIC source files?) So you really want a tool that has lots of parsers that handle the various dialects, and that should drive your choice IMHO.

I think ANTLR has a lot of language definitions (more than JavaCC) so it kind of qualifies. However, many the grammars at that site are experimental or unfinished (some are pretty good) so you get kind of pot luck.

Our DMS Software Reenginering Toolkit has a lot of grammars, and we think it our task to make these production quality. We aren't perfect either but our grammers tend to have been tested on large bodies of code, and have support for various dialects. Error recovery is built in, and you do get a tree back (with error nodes in the AST) if the number of errors is less than a specified threshold. DMS also handles nasty issues such as character encodings (we do a wide variety including 80 column EBCDIC with card numbers in column 72 for IBM COBOL and JCL). DMS may not be what you want; for instance, it is not Java based. But we try to make up for that by providing a huge amount of machinery to support post-parsing tasks, such as what you want to do. This machinery includes support for building symbol tables, extracting control and data flows, matching patterns and applying source-to-source transformations, etc. But that's a tradeoff for you to make.

share|improve this answer

You could attempt to modify the grammar, but why not just work from an AST such as that available from Eclipse?

In the end this will likely be more reliable than most grammars you'll find on the net.

share|improve this answer

There is an article about error recovery with javacc here.

share|improve this answer
That's all nice and documented, but it doesn't give much a clue as to how to patch the AST being constructed. OP will need to do that. –  Ira Baxter Nov 7 '11 at 7:48

I've had great success with SableCC for Java. It's surprisingly easy to use and has a Java 1.5 grammar available

share|improve this answer

Your Answer


