FWD » Core Development » Runtime Infrastructure

com.goldencode.p2j.oo.json.objectmodel.JsonObject throws errors using undoThrow, that is explicit LegacyErrorException and the logs get recorded by LOG-MANAGER even with no-error.

Reproducible in testcases with:

using Progress.Json.ObjectModel.JsonObject from propath.

define variable jsonObj as JsonObject.
define variable objRes as JsonObject.

jsonObj = new JsonObject().

objRes = jsonObj:GetJsonObject("no_name":U) no-error.

produces the log: (Procedure: 'GetJsonObject Progress.Json.ObjectModel.JsonObject') Call to Progress.Json.ObjectModel.JsonObject:GetJsonObject( ) failed. Property 'no_name' was not found. (16058)

8383a based on trunk r15055.

8383a r15058 ready for review.

I've decided on an imperfect solution that will hopefully work for all cases. Since I'm not able to find criteria when an exception will be handled by two (or more) blocks, I've just added a flag to mark when the error is already displayed and not repeat it. There are a few more issues solved, these are regressions I've found in my test procedures: error message added with AddMessage was not displayed (and I know it worked in the past), so here it is back. Also for some reason it seems the callstack has the procedure name in the last instead of the first entry, at least in the JsonObject example, so it's fixed as well.

Constantin Asofiei wrote:

• in OE, SysError is used for internal errors (via ErrorManager for FWD). But, there is nothing stopping the application saving the error instance in a variable and re-throwing it. The point is: the instance can be re-used, and having the 'displayed' flag at the instance doesn't look OK.

In this case the solution won't work. It's impossible to follow all the routes of errors in FWD and reason about solutions that work for all, that's why old functionality gets broken often. The fact that an error is thrown, caught, re-thrown, caught on another level is bothersome.

Also, what files exactly do I need to convert to run the test_apperror.p test?

Probably:

oo/progress/lang/apperror/test_catch.p
oo/progress/lang/apperror/test_constructor.p
oo/progress/lang/apperror/test_methods.p
oo/progress/lang/apperror/test_no_error.p
oo/progress/lang/apperror/test_properties.p

After having a better look at the test I think it's not related to the changes. Nevertheless I ran it just to check if any random regression didn't appear, since it was the closest.

Constantin Asofiei wrote:

Galya, some notes:

• we need to be careful with naming FWD internal methods added to skeleton classes/interfaces (in p2j.oo) - in LegacyError, isDisplayed and setDisplayed names may collide to some app-level implementation of the AppError. I don't have a good solution for this, other name prefixing them with an underscore.

r15059 up, renaming the methods to have underscore.

• in OE, SysError is used for internal errors (via ErrorManager for FWD). But, there is nothing stopping the application saving the error instance in a variable and re-throwing it. The point is: the instance can be re-used, and having the 'displayed' flag at the instance doesn't look OK.

I really can't think of a way to throw the same error twice without catching it. When the error is caught or in silent, it is not supposed to be displayed. When the error is thrown, but not caught, it's displayed, but it ends the execution of the application, so there is no chance of re-throwing / re-displaying it. Do you have something else in mind?

This example adds only one log in OE:

block-level on error undo, throw.
using Progress.Json.ObjectModel.JsonObject from propath.

define variable jsonObj as JsonObject   no-undo.

jsonObj = new JsonObject().

do on error undo, throw:
  jsonObj:GetJsonObject("non-existent-key").
  catch e as Progress.Lang.Error :
    message "in catch".
    undo, throw e.
  end catch.
end.