Chris Rebert <pyb...@rebertia.com> added the comment: >> (2) Target file doesn't exist >> (4) No application is associated with the file type in question > I think that instead of mapping error codes to custom exceptions, which is > fragile and not trivial to maintain, we should just catch stderr and raise > something like OSError(stderr)
It runs counter to the goal of a cross-platform API if *all* the errors are platform-specific. I grant that a generic API cannot wrap *every* possible error, but (2) and (4) are amongst the most common+obvious failure modes and are (FWICT) explicitly reported by all 3 native interfaces. If we don't consolidate them, we'll basically be condemning non-trivial users to copying (or writing themselves, probably inferiorly) a chunk of boilerplate recipe code, and if we're fine with that, then why bother having (this in) the std lib at all? I don't think the handling code for them would be particularly fragile/onerous; we're talking a mere ~2 constants per platform, all tied to pretty-unlikely-to-change native interfaces. For context, here would be (AFAICT; I only have a Mac ATM) the constants in question: Windows: function return value: ERROR_FILE_NOT_FOUND, ERROR_PATH_NOT_FOUND SE_ERR_NOASSOC xdg-open (*nix): exit code: 2 3 Mac OS X: exit code 1 w/ stderr output: "The file XXX does not exist." "No application knows how to open XXX." ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3177> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
