An END code block is executed as late as possible, that is, after perl has finished running the program and just before the interpreter is being exited, even if it is exiting as a result of a die() function. (But not if it's morphing into another program via exec, or being blown out of the water by a signal--you have to trap that yourself (if you can).)

Emphasis mine. This suggests to me that updating a database would be Too Much for an END block.

But then, I'm just a Perl Pisher. One of the Perl Hackers should have something more definitive to say.

Yeah, reading that doesn't exactly fill me with confidence. Maybe we're misinterpreting it, but it does seem to suggest that the rest of the program (modules, etc.) could be inaccessible by the time END gets run.

I don't know where you got that idea that there's a limit. You can do as much as you want. END blocks are called *before* global destruction, so perl is a perfectly normal state.

That said, it's rather odd that you would have to use END blocks. You should find a destructor or Object::Destroyer more appropriate in many circumstances.

I want to say I actually read that on this site, but like I said, I can't find it now.

I don't have to use END, but I think that's a little more elegant than having a bunch of scripts that have to call the same method at the end.

Thanks for the link to that module though, it looks interesting.

IMHO stuffing the END block is just not good style. I would use END only in small scripts, bigger programs should be written with few and well known exit points

If you have lots of die calls in your program it might be better to substitute the die calls with a subroutine that does the cleanup before dying. So that you can differentiate between normal and emergency (i.e. die) exit.

but maybe the module you use for database access has "closed shop" at that time already.

Why would modules spontaneously "close shop"?

Other than making sure the module gets loaded before the END block is compiled, there should be no issue.

Because they had their END block already called and within closed files or dropped connections

Ok, this is far fetched, but as long as you haven't read the module source code you can't be sure the module writer didn't have same ingenious or dump idea how things could be done better or cleaner. You are relying on a feature the module author never even thought of, an internal detail that just is correct for at least 99% of all modules. And maybe wrong for just the module you are using

I know this is true for alarms, but I'm not aware of it being true for END blocks. I'm not so sure that I'd say it's not true for END blocks... Personally, I'm very curious to see what kind of responses you get.

It all depends on whether you want the code executed after a die call or not. Remember that the code inside the END block will be executed after a die. So if, as in your case, the database was not successfully opened, your END code needs to detect that. Other than that one caution, I wouldn't hesitate to put what you need into an END block. That is what it is there for.

Do as little as you possibly can in your handler; notice how all we do is set a global variable and then raise an exception. That's because on most systems, libraries are not re-entrant; particularly, memory allocation and I/O routines are not. That means that doing nearly anything in your handler could in theory trigger a memory fault and subsequent core dump.

It's quite possible I got END blocks confused with signal handling, although I've never read that book. Thanks for the link.

It seemed to work as intended, and if you have any reservations about Perl's ability to perform complex operations in the end block, committing some state information to a flat file may be a good Plan B.