Meaning of RuntimeError

What does the name RuntimeError really mean:

  • is it an error with/from Python runtime, or
  • is it an error that happened at run time
  • something else to do with runtime or run time…

The quip in the docs is that it’s “any other error”, while some specific RuntimeErrors are pretty low level, like recursion limit exceeded or stop iteration conversion.

THe reason for asking is the use of if xx: raise RuntimeError("cannot blah blah") in some library/pr that I’m reviewing.

What does the name RuntimeError really mean:

  • is it an error with/from Python runtime, or

This is what I gather it originated for.

THe reason for asking is the use of if xx: raise RuntimeError("cannot blah blah") in some library/pr that I’m reviewing.

I personally use it for internal logic errors: something I should not
have let the code do. Particular since it isn’t something people will
tre/except to catch - it thus should get me a stack trace.

When I say logic errors: there’s a thin line between using an
if-raise-RuntimeError and an assert.

I tend to use asserts for stuff which should be true. But
if-raise-RuntimeError for something I know is going wrong and I want to
diagnose, or something which really should not process because outright
wrong and potentially dangerous behaviour might follow (eg removing a
file which should not be removed).

I think I thonk of assertions as consitency checks for things I expect
to be true, particularly things which the following code expects to be
true.

For me, raising RuntimeError is for serious failures of implementation.
It isn’t for situations like raising ValueError, when I’ve been given a
bad value. It’s for situation which should never occur, particularly
things which imply a bad decision or action earlier.

Here’s a place where I have a permanent in-my-code RuntimeError:

 def apply_opt(self, opt, val):
   ''' Apply command line option.
   '''
   options = self.options
   if opt == '-o':
     options.ontology_path = val
   elif opt == '-P':
     options.physical = True
   else:
     raise RuntimeError("unhandled option")

This is option handling code, and this code gets called after a getopt()
call which only supports -o and -P. Here, reaching the RuntimeError
means that there’s a mismatch between my option parsing (the getopt()
call) and the option handling code (above). Probably I added a new
option and failed to handle it here.

1 Like

One could argue that the example above should raise a ValueError because the value for opt passed to the function is erronious, at least from the implementation point of view.

And if there’s a spec that allows other values for opt then… I dunno, maybe NotImplementedError? Though I do have some reservations…

One could argue that the example above should raise a ValueError
because the value for opt passed to the function is erronious, at
least from the implementation point of view.

Maybe. But to me this example is a gaping hole in my implementation.
It is something which should go bang and elicit an immediate fix.

And if there’s a spec that allows other values for opt then… I
dunno, maybe NotImplementedError? Though I do have some
reservations…

A decent argument for NotImplementedError, which I had only been
thinking of in the context of abstract classes.

I’ve decided this is a good idea.
https://hg.sr.ht/~cameron-simpson/css/rev/3fe6ebd0d29540930409f286e63b7d87412084bd