Recover From Errors (Solution)

Could ask the user to enter a float to test the program too. Just an idea.

Here is an alternative solution by using built-in string methods

while True:
    number = input('Enter a number: ')
    if number.isdecimal():
        number = int(number)
        print(f'You entered: {number}')
        break

    print('You entered an invalid number. Try again!\n')

Hello, here is my solution below. But I would like to know are there any guidelines on how many lines of code it is considered acceptable to have in the “try”-block of code. Can an all relevant logic be put inside the “try”-block regardless of number of lines of the code that it takes or should it be split so that some small part is located inside the “try”-block and the rest is only after the “except”-block.

while True:

    try:
        user_input = int(input("Enter an integer: "))
    except ValueError:
        print("Try again!")
        continue

    print(f"You've entered an integer {user_input}")
    break

@RV There are no strict guidelines or limitations on the number of lines of code that should be inside a try...except block. However, there are best practices to consider when deciding how much logic to include within a try block:

1. Keep try Blocks as Small as Reasonable: It’s generally a good idea to keep try blocks as small and focused as possible. Only include the lines of code that you expect might raise the exception you’re handling. This makes it easier to understand what part of the code might fail and improves the readability of the error handling logic.

2. Limit Unintended Exception Capture: If you include too many lines in a try block, you might unintentionally catch exceptions from other parts of the code that you don’t expect to fail. This can mask bugs or make it harder to debug. The goal is to catch exceptions specifically where they are likely to occur.

3. Separation of Concerns: Consider splitting the logic so that the try block handles the risky code (e.g., file I/O, network requests) and subsequent logic is outside the try block. This ensures that only the necessary parts of the code are under the umbrella of error handling, and any unrelated logic doesn’t get caught in the same try block.

4. Avoid Using try for Flow Control: Try not to overuse try blocks as a general flow control mechanism. Exceptions should represent actual exceptional situations, not routine events.

Sometimes a longer try block is necessary if multiple related operations depend on one another and could fail together, or if you’re handling complex transactions, for example some database operations.

Generally it’s better to err on the side of keeping the try block small and focused. However, if splitting the logic outside the try block doesn’t make sense or leads to code that’s harder to understand, you can include more lines in the try block.

Martin, thank you for your comprehensive reply!