[Python-Dev] EINVAL (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Thu Jul 22 12:33:02 CEST 2010
- Previous message: [Python-Dev] Python signal processing question
- Next message: [Python-Dev] EINVAL
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, 22 Jul 2010 17:50:00 +0900 "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
Greg Ewing writes: > Glyph Lefkowitz wrote: > > > The selection of RuntimeError in this particular case seems > > somewhat random and ad-hoc,
Well, I guess we'd have to catch the person who wrote the code and ask. > Maybe this is something that could be considered in the > exception hierarchy revamp proposal that was posted recently? I think that's Antoine's PEP 3151. Interestingly, he doesn't mention EINVAL at all. http://www.python.org/dev/peps/pep-3151/
That's right. It is based on a survey of existing exception-catching code in the stdlib. There's only one match in the whole Lib/ subtree:
$ grep -r EINVAL Lib/ Lib/plat-sunos5/STROPTS.py:968:EINVAL = 22
I guess EINVAL would most often indicate a programming error, which is why it doesn't get handled specifically in except clauses. Semantically, EINVAL seems close to ValueError. If I search inside the man pages here, I get excerpts such as:
wait(2):
EINVAL The options argument was invalid.gettimeofday(2):
EINVAL Timezone (or something else) is invalid.socket(2):
EINVAL Unknown protocol, or protocol family not available. EINVAL Invalid flags in type.rename(2):
EINVAL The new pathname contained a path prefix of the old, or, more generally, an attempt was made to make a directory a subdirectory of itself.
Regards
Antoine.
- Previous message: [Python-Dev] Python signal processing question
- Next message: [Python-Dev] EINVAL
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]