FWD » Core Development » Base Language

There are cases when even if an ERROR condition is supposed to be morphed into a structured exception, and re-thrown up the stack, this is not happening. Depending on the business logic, this can lead to infinite loops, like if there is a DO WHILE TRUE which never gets finished.

Marian: Where are we with testcases for ON ERROR UNDO, THROW?
Constantin: Do we have a standalone testcase to recreate the infinite loop in #7417?

Greg Shah wrote:

Marian: Where are we with testcases for ON ERROR UNDO, THROW?

We have tests for error handling in tests/error_handling folder, I've just pushed some changes to it mainly because our AssertExt library got changed at some point at those tests were failing for no good reason :(

Basically the tests focus on how errors are morphed in ProError objects when catch is used and the other way around how an AppError thrown affects the error-status system handle if not catch. Beside that we tested the effect of block-level and routine-level error handling in methods, function, procedures and blocks. I do not think we have tests for default error handling for all blocks but we can maybe add those to somewhere if needed.

I do not think we have tests for default error handling for all blocks but we can maybe add those to somewhere if needed.

This isn't really about default handling. It is specifically about how ON ERROR UNDO, THROW affects control flow. We have at least one issue, in iterating blocks.

Greg Shah wrote:

I do not think we have tests for default error handling for all blocks but we can maybe add those to somewhere if needed.

This isn't really about default handling. It is specifically about how ON ERROR UNDO, THROW affects control flow. We have at least one issue, in iterating blocks.

I stand corrected, all this should be already there - all variations for ON ERROR on all blocks are tested with all error handling options (default/block/routine). I did ran a conversion now on those tests and there are compile errors after conversion - mainly undoReturnErrorTopLevel doesn't have an override using ProError.

Marian Edu wrote:

undoReturnErrorTopLevel doesn't have an override using ProError.

This is for the return error <ProError> statement, can be solved from conversion to translate to undoThrowTopLevel or just add an override undoReturnErrorTopLevel(object error) in BlockManager to do the throw.

I did the later just to be able to ran the tests and there are 64 failures out of 527 tests. Some of them are just caused by the conversion when unknown (?) is passed directly as parameter to a method call, this one is simply ignored and although the method have multiples parameters only the non-null ones are passed. I'm surprised this is not an issue in any decent OO code base, it's pretty common to pass ? directly - I do think we had to resort to use a variable previously but really it doesn't make any sense to do so :(

If you want me to look into those error do let me know otherwise the test cases are there to be used.

Marian Edu wrote:

Some of them are just caused by the conversion when unknown (?) is passed directly as parameter to a method call, this one is simply ignored and although the method have multiples parameters only the non-null ones are passed.

This is actually only the case for function calls, for both methods and procedures unknown parameters seems to be passed just fine, sorry for the confusion :(

Artur: Please make all of these testcases work properly, including the conversion fixes. Constantin, Marian and I will provide guidance, so keep us well informed by posts in this task.

Marian: We also need to ensure that we have at least one testcase that reproduces the infinite loop.

can be solved from conversion to translate to undoThrowTopLevel or just add an override undoReturnErrorTopLevel(object error) in BlockManager to do the throw

I'm inclined toward the BlockManager change. Constantin: What do you think?

Marian Edu wrote:

Marian Edu wrote:

Some of them are just caused by the conversion when unknown (?) is passed directly as parameter to a method call, this one is simply ignored and although the method have multiples parameters only the non-null ones are passed.

This is actually only the case for function calls, for both methods and procedures unknown parameters seems to be passed just fine, sorry for the confusion :(

We need to fix it.

For this test:

routine-level on error undo, throw.

def temp-table tt1 field f1 as int.

procedure proc0.
  do while true:
     run proc1.
     pause.
  end.
end.

procedure proc1.
   find first tt1 no-error.
   tt1.f1 = tt1.f1 + 1.
end.

run proc0.

I have an explanation (and patch): if routine/block-level exists, then an ERROR condition is not actually morphed into a structured legacy exception, but the top-level block is marked as 'trigger error in caller' - this allows the ERROR condition to 'escape' the top-level block into the caller.

Will test more tomorrow.

• Once a structured exception is re-thrown, mark it as explicit, so it can be re-thrown via top-level blocks.
• An ERROR condition must be triggered in the caller (outside of the top-level block) is current file has ROUTINE-/BLOCK-LEVEL statements and this condition can't be morphed in a structured exception in the current stacktrace.

Code Review Task Branch 8799a Revision 15277

I'm good with the changes.

8799a passed #7156 customer testing and other unit tests.

Branch 8799a was merged to trunk rev 15279 and archived.

Constantin Asofiei wrote:

• Once a structured exception is re-thrown, mark it as explicit, so it can be re-thrown via top-level blocks.

I wonder if this solves the logging twice of the same error I encountered in #8383-8.

Greg Shah wrote:

Do you think that 40% is accurate for %Done?

We need to run the tests from xfer - we'll now more after that.