defer isn't bullet proof either. I think there's a linter about it and os.Exit.

One can just wrap os.Exit in a helper to get the expected behaviour.

I would expect to have a method that explicitly stops program execution immediately without further side effects.

An unresolved promise that causes other code to be skipped while program execution continues after the block is, well, unintuitive to say the least.

▲

Joker_vD 2 days ago | parent | prev [-]

Also, if you pull the power plug, neither finally blocks nor defers would run. I personally consider it a clear and obvious deficiency in the semantics (and the implementations) of those programming languages but everybody refuses to listen to me.

▲

gtowey a day ago | parent [-]

Back in the days of spinning rust, we had RAID controller cards with batteries, so that if someone pulled the plug, there would be enough power to keep the drives going until any buffered writes were completed.

I certainly wouldn't mind if modern servers had something similar to make sure programs could stop gracefully. But then that doesn't help if you have a hardware failure...

	▲	Joker_vD 5 hours ago \| parent [-]
		Apparently, Windows does have precisely that, FlushFileBuffers [0][1]. The analogue in the Unix world is fsync(). Of course, some hard drives lie about actually having written their caches down, in which case there is nothing much anyone can do. [0] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/... [1] https://devblogs.microsoft.com/oldnewthing/20170510-00/?p=95...