13

Python's built-in exception documentation defines LookupError as:

The base class for the exceptions that are raised when a key or index used on a mapping or sequence is invalid: IndexError, KeyError. This can be raised directly by codecs.lookup().

Should this base class be used only when catching try sections that access dictionaries using both indices and keys when one wants to shorthand catching both, or is there another case where you would use it?

spookylukey
  • 6,380
  • 1
  • 31
  • 34
Veltzer Doron
  • 934
  • 2
  • 10
  • 31
  • 1
    The only other way I can think of is you've defined a class yourself, and have an error you want to raise that doesn't fit under IndexError or KeyError – Sean Breckenridge Mar 04 '18 at 15:17
  • You mean an error class that inherits from LookupError, I see, but is this actually done under some circumstances? – Veltzer Doron Mar 04 '18 at 17:42
  • 1
    I don't think its good practice to catch a `LookupError` in code that could potentially raise a `KeyError` or `IndexError` (unless you just want to ignore it). If you're sure that nothing other than your code could throw a `LookupError`, theres nothing _wrong_ with throwing one, there are just usually better options (subclassing your own exception). There is an [example here](https://stackoverflow.com/q/35861482/9348376) of NTLK throwing an LookupError when it can't find a file. – Sean Breckenridge Mar 04 '18 at 17:53
  • Hmmm... I took a quick look at the nltk/data.py code, looks simply like bad programming to me (probably should have been file not found or some nltk proprietary exception of some sort), thanks – Veltzer Doron Mar 04 '18 at 18:01

1 Answers1

5

First of all dictionaries only use keys (see: How to index into a dictionary?).

If you are a lazy person you cold catch both KeyError and IndexError with the LookupError (lest say you have a dictionary filled with lists). Never the less i would prefer to catch them separately with two different exceptions. E.g.:

try:
    # do some stuff here
except KeyError:
    # key error handling
except IndexError:
    # index error handling

This way you can respond to these exceptions in different ways, as they were caused by different events. Furthermore there might be other exceptions that are a variation of a LookupError (see below) and you do not want to catch these exceptions as well (same reason one does not simply use except:).

Another way to use the LookupError could be if you are in need of your own exception, as your error that this exception represents is nether described by a KeyError, nor an IndexError, but is a type of LookupError. In this case your custom exception could inherit from LookupError.

Veltzer Doron
  • 934
  • 2
  • 10
  • 31
Benedikt H
  • 64
  • 3
  • 1
    Have you ever seen this actually used?, Only thing that won't strictly fall under other exceptions is maybe using non hashable keys for accessing or something – Veltzer Doron Mar 04 '18 at 17:48
  • 1
    @VeltzerDoron I have seen `LookupError` been used many times with the set method `pop()`. I think that's a good example because though `pop()` raises a `KeyError` if the set is empty, I think `LookupError` is a better fit here because `pop()` removes a random element from a set and it takes no parameters. Normally when you hear of `KeyError`, the first thing that comes to mind is that the key you passed in as parameter doesn't exist whereas that's not really the case here. – Eyong Kevin Enowanyo Jul 22 '21 at 04:27