Message157258
>> (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." |
|
Date |
User |
Action |
Args |
2012-04-01 06:31:36 | cvrebert | set | recipients:
+ cvrebert, vstinner, giampaolo.rodola, benjamin.peterson, eric.araujo, ganadist, Arfrever, cool-RR, rosslagerwall, Roman.Evstifeev |
2012-04-01 06:31:36 | cvrebert | set | messageid: <1333261896.41.0.117948428769.issue3177@psf.upfronthosting.co.za> |
2012-04-01 06:31:35 | cvrebert | link | issue3177 messages |
2012-04-01 06:31:34 | cvrebert | create | |
|