[issue19672] Listing of all exceptions for every function
New submission from Sworddragon: 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. -- assignee: docs@python components: Documentation messages: 203535 nosy: Sworddragon, docs@python priority: normal severity: normal status: open title: Listing of all exceptions for every function type: enhancement versions: Python 2.7, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19672] Listing of all exceptions for every function
R. David Murray added the comment: 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. -- nosy: +r.david.murray resolution: - rejected stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19672] Listing of all exceptions for every function
Sworddragon added the comment: 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19672] Listing of all exceptions for every function
R. David Murray added the comment: If switching to error codes would solve your problem, then catching Exception at appropriate places should also solve your problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19672] Listing of all exceptions for every function
Sworddragon added the comment: 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
