`CreateFailed` should wrap the underlying error if any

[althonos]

Hi Will,
while I was working on fs.sshfs, I noticed that since fs.open_fs is expected to always raise CreateFailed when something goes wrong, it's not really easy to report what really went wrong.

I think that the CreateFailed exception should probably expose a exc attribute, like OperationFailed does. This way, it would be easier to manage the failed creation, depending on whether it comes from a PermissionError, a TimeoutError, a ResourceNotFound when create=False, etc.

What do you think about this ?

[willmcgugan]

👍

[ReimarBauer]

Also raising that "universal error" gives the impression that we always need write access, which is wrong.

[althonos]

Well, actually a CreateFailed exception is raised when a FS object could not be instantiated, not when a filesystem could not be created. Documenting this in the CreateFailed docstring is enough IMHO.

[willmcgugan]

The name may be misleading. CreateFailed may be confused with the use of the word 'create' in the context of writing something.

We might want to think about a more descriptive name. Although we're stuck supporting CreateFailed for backwards compatibility.

[althonos]

But we could create a new class (e.g. InstantiationFailed) and make CreateFailed simply an alias: then everywhere the error would actually be displayed as InstantiationFailed, etc.

That would be like IOError becoming an OSError alias from Python 2 to 3: you can still write except IOError so your codebase is OK but you'll never see IOError in any traceback.

[willmcgugan]

Thanks @althonos for the fix.