Project

General

Profile

Bug #4852

ErrorManager throws 'invalid' ErrorConditionException

Added by Marian Edu almost 4 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:

History

#1 Updated by Greg Shah almost 4 years ago

  • Start date deleted (08/12/2020)
  • Description updated (diff)

From Marian:

We have a situation where ErrorManager.recordThrowError does not set the Progress error code on the ErrorConditionException. The cause seems to be the use of a different constructor (error, code) instead of (code, error), this one is setting the 'key' but leave the progressErrorCode unset (-1).

Is that something done in purpose? How can we get along this if changing the code to use the right constructor is not an option? What we try to do is to do an assignment to validate the input date and if that fails add additional error messages so I'm catching that ErrorConditionException and then use recordThrowError with an array of error number/messages.

This is at line 1438 in ErrorManager, if we can switch the order of parameters errmsg and num then our issue is gone :)

Argh, it looks that way the error number is appended twice at the end, a solution is not to clear pending errors but only throw the new ones we need so not an issue anymore, still this might be 'fixed' if not by-design.

#2 Updated by Greg Shah almost 4 years ago

public ErrorConditionException(int progressErrorCode, String message) is meant to raise an ERROR that has a specific 4GL error number.

public ErrorConditionException(String message, int keycode) is meant to raise an ERROR which does NOT have a specific 4GL error number but is instead caused by a key press (e.g. END-ERROR caused by an F4 in ChUI can raise ENDKEY or ERROR depending on the runtime state). This would not have a 4GL error number associated but we must remember the key (as in keyboard) code that was the cause.

This is at line 1438 in ErrorManager, if we can switch the order of parameters errmsg and num then our issue is gone :)

I agree this looks wrong. The public ErrorConditionException(String message, int keycode) form is meant to be used on the client side. I don't think it should be used in the EM.recordOrThrowError() which is meant to manage 4GL error codes. I think you can swap the parameters.

#3 Updated by Constantin Asofiei almost 4 years ago

Yes, the parameter order is wrong and needs to be fixed (by switching them).

Marian, regarding your original case which exposed this problem: please make sure that, if the 4GL statement has a NO-ERROR clause, the NUM-MESSAGES, GET-MESSAGE() and GET-NUMBER() all report the expected values.

Also available in: Atom PDF