Project

General

Profile

Bug #5046

ErrorManager - recordOrShowError

Added by Marian Edu over 5 years ago. Updated over 5 years ago.

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

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

History

#1 Updated by Marian Edu over 5 years ago

The method recordOrShowError in ErrorManager is used all over the place in FWD but this one does not work well with error handling mechanism, at least in our tests. If that flow leads to a case when this method is being called even if we have our calls wrapped in NO-ERROR (silent) the error is shown as if not handled or NO-ERROR was not used and as such the modal error dialog is shown and ERROR-STATUS is not set either.

Up until now we've simply updated the places where that method was called and replace it with recordOrThrowError but looking now at the call hierarchy that method is being called a lot. Would it be possible maybe to fix that one to take into consideration the error handling mechanism of the block being executed?

#2 Updated by Constantin Asofiei over 5 years ago

Marian, please provide a testcase where you had to change existing FWD code to use recordOrThrowError. We've seen cases where recordOrShowError is really needed, but maybe that was used too aggressively.

#3 Updated by Marian Edu over 5 years ago

Constantin Asofiei wrote:

Marian, please provide a testcase where you had to change existing FWD code to use recordOrThrowError. We've seen cases where recordOrShowError is really needed, but maybe that was used too aggressively.

One example that come to my mind is in BaseObject on method clone, when in OO part was easier to change that as it definitively does not need to pop the error to the user if no-error was used or there is a catch block somewhere up the stack to handle it.

There were indeed cases where an error could not be catch, nor avoided using no-error - those are the so called 'stop conditions', on-stop was used to handle those separately. Things are changing even for those and in latest release a new stop exception was added to be able to handle those cases using try/catch error handling. One example notable example here is probably the CONNECT raising error 748 (no resources available), there were more but this was really more an exception than the rule.

Where we see that happening now is on temp-table/dataset when accessing handle properties that are not valid for the given handle type or when a particular field is not found in a buffer, those are definitively not STOP conditions but I guess the only option here is to go ahead and change from 'show' to 'throw' as needed and eventually only those raising STOP conditions will be left with 'show', is that the correct approach?

Also available in: Atom PDF