EX48 Alternative To Try-Except

Python
#1

Below is the code I came up with for EX48. Rather than creating a try-except statement, I wrote a mini for-loop with an if-else statement. For some reason I feel like this is a hacky way. Works great and doesn’t puke Value Errors from any tests I did. Is this acceptable or is try-except recommended in situations like this?

lexicon = {'north': 'direction',
           'south': 'direction',
           'east': 'direction',
           'west': 'direction',
           'down': 'direction',
           'up': 'direction',
           'left': 'direction',
           'right': 'direction',
           'back': 'direction',
           'go': 'verb',
           'kill': 'verb',
           'eat': 'verb',
           'the': 'stop',
           'in': 'stop',
           'of': 'stop',
           'from': 'stop',
           'at': 'stop',
           'it': 'stop',
           'door': 'noun',
           'bear': 'noun',
           'princess': 'noun',
           'cabinet': 'noun',
           1234: 'number',
           3: 'number',
           91234: 'number'
           }

user_input = input('> ')

def check_input(split_words):
    new_list = []
    for i in split_words:
        if i.isdigit():
            new_list.append(int(i))
        else:
            new_list.append(i)
    return new_list

def scan(sentence):
    results = []
    split_words = sentence.split()
    checked_list = check_input(split_words)#checks and converts user input numbers to integers
    for word in checked_list:
        get_type = lexicon.get(word)
        if get_type == None:
            results.append(('error', word))
        else:
            results.append((get_type, word))
    print(results)

scan(user_input)
#2

Nah, it’s fine. Depends on how and where you want to handle errors, and on how serious you consider them. If being unable to categorise some words is okay for your application, there’s no need to start throwing errors.

You could even go shorter and provide a fall back value to lexicon.get:

results.append(lexicon.get(word, "error"), word)
#3

From a practical standpoint, I think it’s helpful as a beginner to start thinking about error handling from the start.

Try/except is good because it’s gets you thinking and implementing exception; either internally to you/dev or to the user for correction.

It also educates you to consider user input introduces a number of risks that should be handled in your programs.

Appreciate that might have limited relevance here.

#4

It depends on a few practical considerations:

  1. If most of the data is NOT a digit input, then your code will be slower because it has to run isdigit on every input. Try/except works better in this case because it’s an exception that something is a digit.
  2. If most of the data is unknown then either one is fine since you won’t know if you’ll get any performance gain out of only handling numbers when there’s numbers.
  3. You’ve actually performance tested this and you’ve conclusively determined that you’ll need to use one or the other to speed things up. Until then, go with what makes most sense and is easiest to change and understand.

Otherwise they’re nearly the same.