pull down to refresh
173 sats \ 0 replies \ @netstatic 31 May \ on: Writing software: robustness vs being exact devs
Your question of robustness vs exactness frames the 2 as if they're at odds with each other, you can have both robustness and exactness. The UX problem encountered by your user wasn't about robustness, it was about how you decided to engineer your experience.
If you were going to force an extension for a specific output type, why allow the user to specify an extension at all? Doing it this way is setting them up for failure. It's like if I asked you for advice on something I've already made a decision on.
If you're building on libraries that have this problem, make sure as many inputs that would lead to inconsistent states in the library are disallowed at the user input generated from your code. Never correct things for the user implicitly if you can help it.
Best case is you never allow them to make a mistake in the first place, but if that's not possible, you can catch inputs that would potentially lead to errors and inform the user to take action on a proposed fix. And if you need to implicitly correct input as a last resort, although I can't imagine a scenario where this would be needed right now, then you should absolutely notify the user that this correction happened so that they don't get confused on how they got their output.