Using this small class:
ROUTINE-LEVEL ON ERROR undo, THROW.
CLASS class1 :
CONSTRUCTOR class1(INPUT dothrow AS logi):
IF dothrow THEN dothrow().
END.
METHOD PUBLIC VOID dothrow():
UNDO, THROW NEW PROGRESS.Lang.AppError("error", 1).
END METHOD.
END CLASS.
Doing these tests on 10.2B03:
Test1:
DEF VAR o AS class1.
o = NEW class1(yes).
Test2:
ROUTINE-LEVEL ON ERROR undo, THROW.
DEF VAR o AS class1.
o = NEW class1(yes).
Test3:
DEF VAR o AS class1.
o = NEW class1(no).
o:dothrow().
The result is that Test2 and Test3 do display the error message at the screen, but not Test1.
Why ?
* note that the error is correctly thrown back to caller, it's only the display that is missing).
** note also that if this code is executed on appserver, the error is displayed in the log
FWIW, I see an error in 10.2B04 for Test 1 (all 3 cases, in fact).
Did not try on 10.2B03.
-- peter
Upgraded to 102B04, but I still don't see the error.
However, i did notice that Test1 isn't showing the error when run from OE Architect re-using the project runtime.
I can reproduce it using a brand new project in Architect.
In all other cases below, the error is shown as expected:
- running from the Procedure Editor
- using an OE Architect Run Configuration starting a new OpenEdge AVM
Strange isn't it ?
However, i did notice that Test1 isn't showing the error when run
from OE Architect re-using the project runtime.
I see it now ... I never have my run configs reuse the project runtime and so didn't notice this (I like a clean session, and also it's the only way to work if you're dealing with static constructs).
I think this is definitely worth logging as a bug with TS. I don't know how OEA runs the run configs in this configuration, nor what they do with the errors.
-- peter
Using the project runtime to run stuff is a really bad idea if you are using classes. Esp if you are using forms since you can really mess up the wait-for environment used by the VD, or if you are using statics you can get into some inconsistent state, or if you are using appbuilder and the wait-fors don't exit in the right order.
Always use a separate session to run code.
Run configs have a wrapper around whatever you run that traps for errors and spits them out to the screen as dialog boxes.
Running from the project doesn't have this wrapper because showing error dialogs will block the runtime used by the project which will block compiles and syntax checks and several other things.
If you absolutely must run stuff using the project environment you are responsible for trapping your own errors and handling them properly without using message boxes that block the main (only) AVM thread.
mbaker wrote:
Run configs have a wrapper around whatever you run that traps for errors and spits them out to the screen as dialog boxes.
Running from the project doesn't have this wrapper because showing error dialogs will block the runtime used by the project which will block compiles and syntax checks and several other things.
Then why error dialog is displayed for my other tests ?