Message157247
>> [...] do we get ENOENT if xdg-open exists but not the file?).
> It's unambiguous. Python itself never opens the target file, it just passes the filepath string
> along to the xdg-open command. If Popen raises EnvironmentError, then xdg-open could not be
> executed. If the target file is nonexistent, then xdg-open will exit with status 2 (see
> aforelinked manpage). Entirely different error mechanisms.
You are right, I was confusing the layers! Good then.
> So, the failure cases are:
> (1) Platform doesn't support this feature -> raise NotImplemented
Actually the exception is NotImplementedError. Its doc says that it’s to be used in a method that is intended to be overriden in subclasses, but I think it’s not wrong to
> (2) Target file doesn't exist
> (3) Target file is inaccessible
> (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).
[Victor]
>> It's better to not define the function if the platform doesn't support the feature.
That’s easy to do if we can say detect the availability of a function in the libc, but here the function would depend on a program which could get removed or added between two calls to the function, so we have no choice. |
|
Date |
User |
Action |
Args |
2012-04-01 01:01:40 | eric.araujo | set | recipients:
+ eric.araujo, vstinner, giampaolo.rodola, benjamin.peterson, ganadist, cvrebert, cool-RR, rosslagerwall, Roman.Evstifeev |
2012-04-01 01:01:40 | eric.araujo | set | messageid: <1333242100.81.0.325401772738.issue3177@psf.upfronthosting.co.za> |
2012-04-01 01:01:40 | eric.araujo | link | issue3177 messages |
2012-04-01 01:01:39 | eric.araujo | create | |
|