>Presumably your requirements dictate that your code must do something when getFile fails, so you are obviously going to write a test for that scenario. How do you envision that potential crash condition evading the test? The CPU steps through until getFile fails, then checks if you are running a test and if it so it invents a valid file handle, but if it notices you are in production it returns a corrupt file handle and then crashes? That doesn't make any sense. What does make sense to you that explains how your code will pass tests but fail in production?
Sigh. You said it was a feature. You said v being nil was a feature lol. Now you want to test it to see if it crashes? I'm saying it should be tested, but YOU said it was a feature for golang to always return a valid v. Now I know you're just not aware of what you're talking about.
>If what you are struggling to say is that you have no such requirement to deal with the failure so it is unspecified behaviour, and thus you didn't feel the need to write a test for it, all you can do with sum types, to keep the compiler happy, is purposefully panic. It is unspecified behaviour. Anything else but crashing would be nonsensical – something that is true even if it were written in Rust. Is the source of the panic significant?
I don't need to specify the difference here. You're just being stubborn. You already know that in rust you need to explictly panic vs. golang you can panic mistakenly with a hidden nil. This discussion is over.
Sigh. You said it was a feature. You said v being nil was a feature lol. Now you want to test it to see if it crashes? I'm saying it should be tested, but YOU said it was a feature for golang to always return a valid v. Now I know you're just not aware of what you're talking about.
>If what you are struggling to say is that you have no such requirement to deal with the failure so it is unspecified behaviour, and thus you didn't feel the need to write a test for it, all you can do with sum types, to keep the compiler happy, is purposefully panic. It is unspecified behaviour. Anything else but crashing would be nonsensical – something that is true even if it were written in Rust. Is the source of the panic significant?
I don't need to specify the difference here. You're just being stubborn. You already know that in rust you need to explictly panic vs. golang you can panic mistakenly with a hidden nil. This discussion is over.