I guess we aren't likely to reach an agreement on this. If a resturant put my desert on the table first but told me not to eat it until last, I would probably feel much the same as I do about this.

I appreciate, and implied as much, that my contrived example doesn't hold up to scrutiny, but the point I was trying to make does. If it is legitimate for a module to require an END block to achieve its purpose, then it is also legitimate for my program to have a similar requirement. Your own example probably makes my case better than I can improve upon.

I want to write a program that accesses a DB through a module that use class based DB connection, and an END block to free that connection when the program is cleaning up. Once I have performed my processing, I need to exec a follow-on script. To ensure that all the resources my script uses, directly or indirectly, are properly cleaned up, I place the exec in an END block so that everything gets the chance to clean itself up before I do so.

Except that unless I know that one of the modules I am using has an END block that needs to be called before I exec and take the unusual step of placing my END block at the top of my script before useing that module, then my END block will be called before the modules, the exec occurs and the module never gets it's chance to clean up.

And therein lies the fudge. It may be a reasonable compromise given the architecture, but it is hardly the "right" solution IMO. A correct design would be for the module to have a class method that my program could call to cause the class to explicitly request that it frees off all its resources. That way, I as the main script author can chose when things should be freed, and not have to rely upon explicit knowledge of the calling order of a chain of global events to ensure that my program runs correctly. Of course, if every class/module had such an 'Okay, I'm finished with you so do anything you need to do to clean yourself up' call, then I wouldn't need to use an END block in my code to perform the exec, I could just arrange for it to be the last thing that happened in the normal flow having called the appropriate "I'm done with you" routines, and that would be that.

I can see no logic in the idea that a 'module' should be any more (or less) likely to need to have it's END block called later than my END block? What if I have am using two modules that need their END blocks to be called last. Then which ever order I choose to use them is going to be wrong. The fact that I have to know that I have to use whichever module most needs to have its END block called last, FIRST. Is not just counter-intuative, it's just plain wrong.

There was a recent thread about what order people favour for their use statements. The answers ranged from alphabetical, to pragmas followed by utilities followed by classes, except the vars pragma which which always came last. So far, I haven't hit upon any good reasons to favour any one ordering over any other. They generally get added in what is basically chronological order as I find the need for them. The idea that I should have to scour the source code for each module looking for END blocks and then try and decide what order they should be called in and then reverse that to determine the order of my uses, beggars belief.

I strongly suspect that END blocks came into being as a poor man's 'last gasp', fatal exception clean up mechanism and the real answer is that there should be no inter-module ordering dependancies between them. Were this the case, there would be no need to know what order they execute, which would be a wholey good thing. It would also remove the need to reverse the logical ordering of multiple END blocks within any given source file.

The need for this backward ordering arises soley because the one time exception mechanism has been subverted. People have decided that rather providing an explicit call to perform cleanup and a fatal exception cleanup, they don't need to provide the former and require the caller to use it, because the latter will get called anyway...except that sometimes it doesn't.

I wonder if there is any history of when this ordering decision was made and why. I also wonder if it will persist into P6. Personnally I strongly hope that it doesn't but we will probably have to wait for "Apocolypse N of N" for the answer to that, given that the last Apocolypse would seem to be the logical place to consider END blocks.

But then again, maybe they should have been in Apo 1:)