I just shudder when I hear/see this comment (or something similar to it) and they just cant figure out why. Well here's why:
There are always two ways of doing something:
- Get it working
- Get it working the right way
Most anyone with any programming knowledge at all can get software to work when the happy path is present. And so many students today and perfectly fine with that kind of mentality.
I think any instructor, or employer for that matter, has a serious problem on their hands if they let that kind of mentality exist. What are they going to do when reality hits, i.e; no happy path, and the software they're so proud of pukes all over the user. If there's one things I've learned in my years in this industry it that if something can be broken an end user will find it, and employ it so fast it will make your head spin.
One thing I always tell new programmers is to think like an end user. Get your software working the right way not just get it working. So many students are in such a hurry to have a social life that they just care if it works long enough to be tested, bad answer.
If you want to make it in this industry you need to learn from the start to think long and hard about how an end user can break what you've worked so hard to create. Don't settle for what I call Happy Path Programming, strive for better from yourself. Strive to create software that is as bullet proof as possible. I know it's really impossible to get it 100% fool-proof (because society is always turning our better & better fools), but it pays off in the long run to strive for it.
I seen that statement today on Dream.In.Code, they said
They were fine with catching (or throwing an exception) when the happy path fails. Exceptions cost a lot of overhead, and if you know something can happen if the user enters ABC instead of DEF why not take the time to account for that beforehand? Is it worth the performance hit for a shortcut?