FWD » Core Development » Conversion Tools

This is from #7199-25:

Greg Shah wrote:

Constantin Asofiei wrote:

Greg, there is a simple change in Pattern.processAst - enclose it in a try/catch(Throwable) block, and I think this will not abend the conversion in case of FWD bugs.

I think we need to remove that AST from subsequent conversion steps otherwise it will be a real mess. And when we remove that AST, if it is a class/interface/enum there may be many other dependencies which would break. For this reason, I think the problem is bigger.

• prevent the conversion to abend - this is the Pattern.processAst enclosed in a try/catch proposal
• log any relevant info about the file which abended and why, and collect this file name
• on conversion finish, report the files which abended and terminate with a non-zero exit code.

Regarding this note:

Greg Shah wrote:

I think we need to remove that AST from subsequent conversion steps otherwise it will be a real mess. And when we remove that AST, if it is a class/interface/enum there may be many other dependencies which would break. For this reason, I think the problem is bigger.

I don't necessarily agree that we should remove the AST from the conversion. I agree that if a file fails i.e. during annotation, it will almost certainly fail on core code conversion, too. And it may bring other files to fail, like when a .cls fails and dependent files fail, or shared temp-tables/frames.

We already know that the conversion is in a 'failed' state when we encounter a failed file. But, leaving it in the conversion file list, and all its dependencies, FWD will report these, which will allow us to i.e. convert all these failed files separately (to test the fixes) until we try a full run again.

This may need to work in conjunction with #6082 to automatically pull all .cls files into conversion (but this can be solved manually by running parse first, get all the pre-scanned .cls, add them to the file-cvt-list.txt and run conversion again).

This is really a duplicate of #7179.

I agree that if a file fails i.e. during annotation, it will almost certainly fail on core code conversion, too. And it may bring other files to fail, like when a .cls fails and dependent files fail, or shared temp-tables/frames.

Which will create a large amount of unnecessary noise in the output. People may look at the later problems and miss the earlier root cause. The result of that will be wasted time. Generally, I don't see any value in failures that are downstream of the root cause. They aren't real failures. Reporting them is a net negative.

But, leaving it in the conversion file list, and all its dependencies, FWD will report these, which will allow us to i.e. convert all these failed files separately (to test the fixes) until we try a full run again.

This is not a reason to leave them in. We can just output the list of removed files at the time we remove them, so that it is clear what needs to be re-run.

Danut, please see some changes from 9457c: bzr status -r 16245..16270 - there are either some commented code or abends replaced with logging:

  src/com/goldencode/ast/AnnotatedAst.java
  src/com/goldencode/p2j/pattern/CommonAstSupport.java
  src/com/goldencode/p2j/pattern/PatternEngine.java
  src/com/goldencode/p2j/uast/ClassDefinition.java

Constantin Asofiei wrote:

Danut, please see some changes from 9457c: bzr status -r 16245..16270 - there are either some commented code or abends replaced with logging:
[...]

src/com/goldencode/p2j/pattern/PatternEngine.java changes look similar to what I've done in #6889, but seem incomplete.

#6889 only has the changes for incremental conversion, making this available for all conversions is easy as it only requires moving allFailedSources outside the job.incremental check.

Please merge 7318a to trunk after 11049a.