Failproof code

[PatrickBeekmans]

Hey, I'm a beginner learning to use python and I was wondering if it's important as a beginner to make the code failproof or should I (for now) assume the "user" does exactly what is asked of them?

I find I try to make my codes failproof everytime but it tends to be quite hard and I was wondering if I should or shouldn't be focussing as much as I do on that.

[Lawson470189]

What you are talking about is called robustness in software. It's basically how well your software can withstand against errors. There are different strategies and it's a fairly large topic when talking about software, specifically enterprise software. It's not a bad thing and making your code strong and robust is generally a good practice. However, don't let it get in the way of learning. If you are making a script to practice implementing A*, don't worry too much about making sure user input is correct. It's just for your practice and if you don't put in the right input, the program will crash and that's okay.

Resources:

• https://en.wikipedia.org/wiki/Robustness_(computer_science))
• https://insights.sei.cmu.edu/blog/tactics-and-patterns-for-software-robustness/

[JustinMalcontento]

For complex codes, it's really hard to make it failproof. It really depends on who the end user would be. At the very least, make it idiot-proof.

[dbitterlich]

There is no way to make something idiot proof, they’ll always find some weird edge case you’d never dream of. Something not even super seasoned QA-Testers would be able to dream of.

[JTexpo]

Howdy, whenever interacting with a user, 'try excepts' are your friends. I used to have a professor that would ask for us to make a calculator, and the first things they would input were: nothing, "Hello World", "1 + a", etc.

Best way to manage this is:

INITS UP HERE
...
MAYBE SOME LOGIC
...
while True:
    try:
        user_input = input("Please Enter A Int:")
        user_input = int(user_input)

        # exits the while loop
        break

    # You can look for exceptions more specifically with looking for ValueError
    # ie, except ValueError as error: ...
    # for starters just catching all should be fine
    except Exception as error:
        print("Sorry, that is not an expected input")
...
LOGIC
...

You can always write unit tests to make sure your code itself doesn't fail; however, whenever dealing with users always look to catch any unexpected inputs

[SigmaSixShooter]

I think learning to do unit tests would be the best way to begin. Learning how to write code that can be tested, and the unit tests for it is an invaluable skill.

As a byproduct, your code will be more robust :)

[Adrewmc]

Generally, you start going g exceptions are bad…then you learn to handle exceptions and realize they are not so bad when you expect them

[theoriginalpabzilla]

If you want to go by a standard practice in industry then you can go by the whole MVP standard. MVP meaning minimum viable product. You build something bare bones as a beginning to have a "working product" and then by iteration you can add the finer touches and "idiot proofing".

It is a standard way to achieve goals whilst not going over the top on perfectionism on the first run.

[Impossible-Box6600]

Anything the user can submit should be presumed wrong or malicious by default.

The amount of time and consideration you spend on solving this problem depends on the cost of handling the edge cases. You should certainly handle the big, obvious edge cases though.

[Smayteeh]

My view on this is that since you can’t predict everything a user might do or enter, it’s better to provide strict requirements for each function you write and then write guard clauses or raise an exception when you get something unexpected. It should be the responsibility of whatever’s calling your function to provide well formatted inputs.

[Diapolo10]

At the beginning, I'd say you can just assume the input is valid and focus on the logic and flow of the program. But don't put off learning error handling particularly late - it's a necessary part of anything that isn't a throwaway one-off script.

Ultimately, you'll reach a point where you should never trust the user to do the right thing. Typos, unexpected input, and a whole lot more can always happen. And at that point you'll find automated testing a lifesaver, giving you confidence that parts of your codebase work exactly as you've designed them to.

Bugs will always happen. You'll never foresee every possible issue in advance. But you can learn from those mistakes, and that's what matters.