Looks as if "Close()-like things" all fall into two categories - the usual horrid one, in which you can discover too late something didn't complete, or - the trivial case, in which the pre-close operations are transactional and xxx.Close() only ever returns nil
Which means I have to make my work transactional. In this case I did, but I'm lazy and would really really prefer Tony Hoare to have done that. As usual, I ended up drawing DFAs and boring my colleagues to tears reviewing the correctness of the code that wrote output (to influx) and got a nil error back before it marked the input (from Kafka) as having been read. That and a bunch of code-reading allows me to treat this (one! singular! individual!) case of a failed close as a harmless horrible thing. A thing that requires me to rerun the program, so that it can re-read anything that I haven't marked as committed. Sigh. Safety-critical system development is cool, but it's not *fun* unless you like brain pain. Or writing proofs in prolo(n)g. --dave (admitted nerd, but not masochist) c-b > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
