This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Listing of all exceptions for every function
Type: enhancement Stage: resolved
Components: Documentation Versions: Python 3.3, Python 2.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Sworddragon, docs@python, r.david.murray
Priority: normal Keywords:

Created on 2013-11-20 21:49 by Sworddragon, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (5)
msg203535 - (view) Author: (Sworddragon) Date: 2013-11-20 21:49
Currently the documentation does sometimes say about specific exceptions but most times not. As I'm often catching exceptions to ensure a high stability this gets a little difficult. For example print() can trigger a BrokenPipeError and the most file functions like flush() can trigger other related IOError's.

So I would like to see something like a listing on every function which contains all exceptions that may appear. Also there are some special cases like close(). For example it can trigger an IOError too if there are pending write operations due to an implicit call of flush(). But if the file object is opened in read-only mode or there are no write operations this can't happen. Maybe such additional information can be added too.
msg203544 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-11-20 23:04
This is not something we are going to do.  We don't know what every exception is that every function can raise.

Adding mentions of unusual special cases that aren't currently documented would be OK, though.  You should open specific issues for things you think should be clarified.
msg203545 - (view) Author: (Sworddragon) Date: 2013-11-20 23:21
I'm fine with this decision as it will be really much work. But this also means programming with Python isn't considered for high stability applications - due to the lack of important informations in the documentation.

An alternate way would be to rely on error codes and abandon exceptions. But this would be a case for a PEP and I'm assuming that it is absolutely unrealistic that this will be changed.
msg203546 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-11-20 23:30
If switching to error codes would solve your problem, then catching Exception at appropriate places should also solve your problem.
msg203547 - (view) Author: (Sworddragon) Date: 2013-11-20 23:35
Correct, but the second part of my last message was just my opinion that I would prefer error codes over exceptions because it implies already a completed documentation for this part due to return codes/error arguments/other potential ways.
History
Date User Action Args
2022-04-11 14:57:53adminsetgithub: 63871
2013-11-20 23:35:16Sworddragonsetmessages: + msg203547
2013-11-20 23:30:47r.david.murraysetmessages: + msg203546
2013-11-20 23:21:58Sworddragonsetmessages: + msg203545
2013-11-20 23:04:09r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg203544

resolution: rejected
stage: resolved
2013-11-20 21:49:29Sworddragoncreate