search

graphicore / ufoJS

Javascript API for the Unified Font Object
lib.ufojs.org
GNU General Public License v3.0
52 stars 10 forks source link

Fix handling of ENOENT #21

Closed rrthomas closed 9 years ago

rrthomas commented 9 years ago

See https://github.com/rrthomas/ufoJS/commit/8edfa4739b39fdb728eb7506455562974f86ece9

We should use _callbackFactory, and raise IONoEntry.

behdad commented 9 years ago

Copy/paste error? :D

rrthomas commented 9 years ago

Oops. Fixed, thanks!

rrthomas commented 9 years ago

Two things here:

  1. I don't understand why we handle ENOENT specially. This is worth documenting and explaining. In particular, why handle it different from other errors?
  2. If we're going to do this, let's have standard wrappers for async and sync methods, and use them throughout the module.
graphicore commented 9 years ago
  1. We should handle other errors as well, but ENOENT is the most prominent.
  2. ok
rrthomas commented 9 years ago

More precisely, why do we handle ENOENT like this at all? We take an exception and turn it into another exception…what's the point?

graphicore commented 9 years ago

This is an abstraction layer, the way we present to the user that a file was not found, for example, should be presented in a uniform way; independent of the abstracted matter. The user shouldn't bother with all the different ways the abstracted API can tells us about the state of an operation. Check the BrowserRest API how a file not found looks there.

graphicore commented 9 years ago

I would put it like this: from an application perspective; when it is desirable to react on a certain kind of error; I'd like to be able to do this the same way, regardless what the abstracted file system is. IONoEntry is such an error: I may wan't to try to open it without checking before if the file exists, because I can handle the error in case it doesn't exists. Other errors where it might be desirable for an application to handle the errors should be the same for all abstracted interfaces. I can think of errors where it may be better to handle it somewhere else, for example, a permission problem is usually not handled by the application directly, that's rather a thing the administrator/superuser/user of the file system should handle; by either changing the permissions or by pointing the application to a location where the permissions are sufficient.

rrthomas commented 9 years ago

OK, I finally understood; sorry: the API we present is not just the file API: the "intersection" of the REST and file APIs is not a strict subset of either. So, I can use the docstrings in _base.js to see what the methods should do (currently, only IONoEntry is mentioned).