In the 10.1C ABL reference on FINALLY, there is this piece of sample code:
The CATCH block inside the DO here differs from other examples because there is no DELETE eSysError. How does it then get cleaned up?
And, why is there no name conflict on the eSysError being used for both CATCH blocks?
Of course, they left out the DELETE eSysError on the outer block too....
because it's supposed to illustrate a concept, not actually work?
Sorry about the formatting. I cannot get the indention to stick.
Surround your code with and (no spaces).
But what about the originally thrown and caught 'e'?
Perhaps this is their way of letting us know that garbage collection will soon be available?
Anyone at Progress happen to be listening to this thread?
Try stepping through it with the OEA debugger and look at the object handles.
Coming from an OO world I would clean it up wherever I decided that I didn't want it to flow any higher.
In this case in the catch in the main block.
"Coming from an OO world I would clean it up wherever I decided that I didn't want it to flow any higher. In this case in the catch in the main block. "
That makes sense to me. My concern is/was that each catch was creating a new AppError object.
There have been several questions raised in this dialogue. I will attempt to address each of them.
From Thomas's posting on 05/17/08:
1) And, why is there no name conflict on the eSysError being used for both CATCH blocks?
In 10.1C the Documentation team introduced the new Error Handling book, which introduces the new Structured Error Handling model as well as the traditional model. On page 7-4, which is describing the CATCH syntax it states (I added thebold):
"error-variable The variable name that references an error object derived from the built-in class Progress.Lang.ProError. Typically, you do not define theerror-variable ahead of time with the DEFINE VARIABLE statement. The AVM recognizes a new variable name on the CATCH statement as a new error-variable definition. Each CATCH in an associated block must have a unique error-variable.You can reuse an error-variable name in a different associated block, as long as its type is compatible with the new definition. For example:"
(I did not include the example from the documentation)
From the same posting - and commented on throughout this forum:
2) The CATCH block inside the DO here differs from other examples because there is no DELETE eSysError. How does it then get cleaned up?
The model that was used for Structured Error Handling is that all unhandled error objects are automatically deleted. A handled (caught) error must be deleted or re-thrown from the CATCH block that caught it. The examples and text in the Error Handling book make this point.
3) Why does this example not do this?
This example is taken from Reference book pages 504, 505, and 506 which describe the FINALLY statement. This section has 3 examples which are used to describe the functionality of the FINALLY block. They build on each other. For the code to be complete the last example, should have either a DELETE OBJECT or THROW of the caught error object. However, this would not be the only example in our documentation in which proper object clean up did not occur. These examples are used to demonstrate a coding concept and should not necessarily be viewed as complete code.
4) Perhaps this is their way of letting us know that garbage collection will soon be available?
We are actively working on the 10.2A release. In this release we are working on introducing Garbage Collection for class based objects (those that inherit from Progress.Lang.Object). Therefore, tentatively in a future release your code will no longer have the requirement to delete the caught error object. This feature will tentatively be part of the 10.2A beta program.
This feature will tentatively be part of the 10.2A beta program.
Evan, you just thrilled a lot of people!
Thanks for your review. That cleared up a lot of things.