Question Any way to manage/track handle/object variable ?

[altair]

Hi,

Hope you are well.
I am new on this forum, and this is my first post. So if I do something wrong, please tell me

For debugging purpose of my application, I was wondering if it there were any way to manage and track handle variable in Progress ABL.
The reason why : this Progress error message :
"

---------------------------
Error (Press HELP to view stack trace)
---------------------------
Invalid handle. Not initialized or points to a deleted object. (3135)
---------------------------
OK Help
---------------------------​

"
This error message can pop-up quite frequently. What is sad with this message is that it doesn't shows up which handle or object (yes, message is the same for class instances) is invalid when trying to access it.
I know it is a standard Progress error message and can't be improved. I also know it is possible to debug manually with some log messages.
But I just want to know if there is any way to find more easily why the error occurs, especially :
- which handle is invalid ;
- where the handle/object gets invalid (the procedure where it is deleted) ;
- possibly the reason why : if it is not a "DELETE OBJECT" statement, maybe the execution of a method, get or set of an attribute ;
Of course, this is very simple to find out in a single procedure. But it is harder when you have about 10 or 20 procedures, classes or includes and some of them executed on appserver side...

So I would like to know if there is any tool (from Progress or community) which can ease this work.

I thought about the debugger, but it is not applicable in my case (architecture issue).
I thought also about a library/classes with functions/methods which will wrap the handle methods/properties and the DELETE OBJECT statement and adding log messages each it is called. But I think it may decrease application performances quite a lot. I don't know if this already exists...

Configuration used : Progress Openedge 10.2B06 on Windows XP (5.1.26000:SP 3)

Thanks a lot in advance for you suggestions/support.

PS: I am french user, so sorry for my English

 

[Cringer]

One thing you can do is to start the client session with the -debugalert parameter. When the error is then presented there is an additional "Help" button. Click on that and it will provide you with a stack trace of where the error is occurring. It will help you track down the issue.
In more general terms, every time you use a handle you should be checking "IF VALID-HANDLE(handle) THEN..." that way you can catch the error before it actually happens, and handle it gracefully.

 

[Stefan]

Press the help button to get the stack trace. The debug-list line number is shown where the error is occurring. This is not the source code line number (unless you have absolutely no include files), so you will need to compile your source with the debug-list option. The alternative is to start the debugger from the stack trace, the debugger then creates the debug-list on the fly.

 

[Cringer]

Ooops didn't realise the Help was already there...

 

[altair]

Hi,
I have already tried the above exposed solutions :
* -debugalert option : yes, but the stack trace when error doesn't show up on our appservers log files :-( ;
* COMPILE ... DEBUG-LIST : yes, but need to recompile the program locally to get it :s ;

But thanks all for your answers
I think I will combine these and try to develop my own library/class to manage handle variables and maybe put tracking information in log files/temp-table ... :-|

 

[oli]

The client logging might help you too.
Select the Log Entry Types "DynObjects.*".
You'll see where dynamic objects are created/deleted.

 

[altair]

Ok, I will take a look about the logentrytypes, seems quite good for what I want to do

Thanks !

 

[Stefan]

Hi,
* -debugalert option : yes, but the stack trace when error doesn't show up on our appservers log files :-( ;

If you add -debugalert to your AppServer startup parameters it will.

You may also want to look into CATCHing all errors and THROWing them up the call stack (definitely lookup BLOCK-LEVEL ON ERROR UNDO, THROW - which is not available until 11.2 or so, before that you only have ROUTINE-LEVEL ON ERROR UNDO, THROW - there is a startup parameter that will add these at compile time). The top level routine on the AppServer can then RETURN the bits you need to the client (unfortunately no THROW across the session boundary).

 

[GregTomkins]

Progress' error messages, and especially not consistently including file names and line numbers ... easily one of the worst things about Progress. Things like -debugalert don't help when you're looking at an end-user screen shot and CATCH doesn't help when it's 20 year old code running in 10.2.

Contrast Java errors, which are in the opposite direction ... dozens and dozens of lines of call stack. Better too much than too little though.

 

[Stefan]

Progress' error messages, and especially not consistently including file names and line numbers ... easily one of the worst things about Progress. Things like -debugalert don't help when you're looking at an end-user screen shot and CATCH doesn't help when it's 20 year old code running in 10.2.

Contrast Java errors, which are in the opposite direction ... dozens and dozens of lines of call stack. Better too much than too little though.

What do you mean with -debugalert does not help?