Project

General

Profile

Code conversion error handling

Added by Antanas Valencius about 3 years ago

Hello,

I am trying to convert a big project, managed to get through the `ant report_server` stage. However, I have issues with the `ant convert` stage. It is really inconvenient running the conversion for multiple hours to run into a process-stopping error during 'Code Conversion Annotations' stage. It crashing makes it difficult to solve errors, because you only solve one error at a time. How do I solve such issue?


Replies (1)

RE: Code conversion error handling - Added by Greg Shah about 3 years ago

I am trying to convert a big project, managed to get through the `ant report_server` stage. However, I have issues with the `ant convert` stage.

It is important to run reports and conversion as 2 separate project directories. Once you run reports you cannot run conversion without a full ant clean step in between (and vice versa). You were probably already aware of that, but I just want to make sure you knew it.

It is really inconvenient running the conversion for multiple hours to run into a process-stopping error during 'Code Conversion Annotations' stage. It crashing makes it difficult to solve errors, because you only solve one error at a time. How do I solve such issue?

I understand it is frustrating, sorry about that. The annotations phase is where we do most of our code analysis so it is very sensitive to the inputs. Here are the most common causes of annotations failures (and also of core conversion failures):

  1. Trying to convert a feature for which FWD doesn't have support (yet). To eliminate these it is important to do an Assessment using the Code Analytics. This will define the list of things which need attention before trying conversion.
  2. Trying to convert when there are existing failures "upstream". This is most often in the parsing or post-parse fixups stage. If you have completed reports processing, you may already have resolved these, but you should check the output very carefully. Any failures in the front end will almost always lead to failures downstream. Clearing these will reduce issues later.
  3. Latent bugs in our conversion rules. Such bugs are often caused by encountering some unanticipated variant of an existing feature. In this case, we must look at the 4GL that is causing an issue and make a fix.

The 3rd case is usually the only one that causes problems, because we make it a part of our process to eliminate the first two classes of problem before we try to run conversion. I don't have a solution for the 3rd case because it is by definition an unexpected bug. We could try to make changes to continue processing when a failure occurs, but that won't work in all cases and it will certainly lead to more failures in downstream steps.

    (1-1/1)