You don't even think timely, well-ordered destructors are important. So what do you know? ;)

The idea is very DWIM and so I think it fits well with Perl. If Perl had better standardization/tools for exception handling, then I'd likely use that much more instead. As is, exception handling in Perl is what I consider to be an "uncommon practice" and likely to surprise people so I usually avoid it (and I regretted one case I can think of where I didn't and in the next release of the module I removed exception throwing).

Because Perl has timely destructors, I don't mind using them. I find them very powerful. There are things that can be done very cleanly in timely destructors that are just plain hard to do without (lock this and without having to remember to put in any code elsewhere, I know the lock will be released when I leave this block; allocate this exclusively and free when we are done with it).

The idea of not having well-ordered destructors just boggles my mind. But that is for another thread.

I also find the distinction between exception and failure (so return a false value) to be a pretty slippery one. One of my favorite things about this idea is that I don't have to decide. I enable you, the module user, to decide which one you want to use and to change your mind depending on the situation.

I also like that it detects coding mistakes where you forget to check whether something failed or not. I really think all Perl's built-in functions should be capable of behaving this way (like use Fatal qw( :void ... ) almost does) at least optionally.