>> If I ever saw such a pattern in production code I would be 99.9% that it was bugged even without looking at what else it is doing.
>> Clean up code should never fail.
> I've seen lots of clean-up code, or finalisation code, over the years that can throw exceptions, for example it if opens a file for logging, or if it writes to a database, or if it sends data out on the RS232 port, or even if it just decrements a semaphore. If one part of the clean-up or finalisation fails, it's better just to get as much clean-up or finalisation done as possible (i.e. don't neglect to write to the database just because the RS232 port failed to write).

I'm not questioning that you have seen such type of code. What I'm questioning is that such type of code is ever good or even correct.
And I'm not saying you don't have a use case for it, I'm saying that experience tells me that it is far more likely that you are hiding problems you are just not seeing.
And in the very unlikely event that you have a valid case where this would be useful, I would rather see a verbose try{func();}catch(...){} code wall explicitly acknowledging the dangerous code behavior than having a single keyword to hide it all.


Your examples just raises further questions.
Like, if you need to change the state of a semaphore to the point that you need to ensure that it gets executed even though other stuff is failing, how can your application be left in a valid state when operating the semaphore itself fails? And how could it even fail if it wasn't already in an invalid state?
Or, why is logging interleaved with a "must execute" cleanup code? Or why does your logging facility throws exceptions at the user's code or tries to open files while user's code is being torn down?

FYI. I don't expect an answer. I'm just pointing out that, this is a big code-smell, you should pay closer attention rather than ignoring it.