7 ms·
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.
by anttiharju 2mo ago
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.
- Joker_vD 2mo agoAlso, 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 1mo agoBack 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 1mo agoApparently, 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/nf-fileapi-flushfilebuffers https://learn.microsoft.com/en-us/windows/win32/api/fileapi/... [1] https://devblogs.microsoft.com/oldnewthing/20170510-00/?p=95505 https://devblogs.microsoft.com/oldnewthing/20170510-00/?p=95...
- gtowey 1mo agoI 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.