3 ms·
>Au contraire: It's the height of good programming to attempt to predict and handle as many real-world errors as humanly possible. If I'm writing a USB device d
by criley 14y ago
>Au contraire: It's the height of good programming to attempt to predict and handle as many real-world errors as humanly possible. If I'm writing a USB device driver, you'd best believe I should try to do something sane if the cable comes unplugged, rather than just saying "don't do that".
Should you devote a lot of your limited programming time to catching an exception that users naturally experience during USB operation and can be corrected by a simple "unplug and replug?"
I argue that you shouldn't devote undue attention to something that users naturally already handle.
But if your project is healthy and features are rolling out and you have the time and talent to waste on edge cases like this, then why not!
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- lukifer 14y agoYou're presuming a lot on behalf of your users. Not everyone will think to unplug/replug; many will just say "it's broken", unplug, put it away and never use it again. > But if you have the time and talent to waste on edge cases like this, then why not! The world is made of edge cases, my friend. :) At any rate, I think the ideal to pursue is the "tick/tock" strategy: roll out new features aggressively, accepting that there will be imperfections; then take the time to fine-tune and backfill. You can't pre-solve every potential problem, but you can try to catch the major ones, and fail gracefully as much as possible.
- deleted 14y ago[deleted]