Nos bénévoles n'ont pas encore traduit cet article en Français. Inscrivez-vous et aidez-nous à réaliser cette tâche !
Vous pouvez également lire cet article en English (US).
This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.
Represents an error that occurs while using the
Note: This interface is obsolete per the latest specification. Use the new DOM4
DOMError interface instead.
In the File System API, a
FileError represents error conditions that you might encounter while accessing the file system using the asynchronous API. It extends the
FileError interface described in File Writer and adds several new error codes.
FileError objects are passed to error callbacks. The objects have a code that shows the type of error that occurred.
Most people don't read the page on errors and exceptions unless they're stumped. So the following are a few tips that could help you avoid some pitfalls.
Error callbacks are not optional for your sanity
Although error callbacks are optional, you should include them in the arguments of the methods for the sake of the sanity of your users. A web app could fail for various reasons, so you don't want to spend the rest of your day guessing what's going on and going through maddening troubleshooting.
Don't run your app from file://
For security reasons, browsers do not allow you to run your app from
file://. In fact, many of the powerful storage APIs (such as File System, BlobBuilder, and FileReader) throw errors if you run the app locally from
file://. When you're just testing your app, and you don't want to set up a web server, you can bypass the security restriction on Chrome. Just start Chrome with the
--allow-file-access-from-files flag. Use the flag only for testing purposes.
||The most appropriate error code for the condition. See Error codes for possible values.|
||5||The URL is malformed. Make sure that the URL is complete and valid.|
||9||The modification requested is not allowed. For example, the app might be trying to move a directory into its own child or moving a file into its parent directory without changing its name.|
||7||The operation cannot be performed on the current state of the interface object. For example, the state that was cached in an interface object has changed since it was last read from disk.|
||6||The state of the underlying file system prevents any writing to a file or a directory.|
||1||A required file or directory could not be found at the time an operation was processed. For example, a file did not exist but was being opened.|
||4||The file or directory cannot be read, typically due to permission problems that occur after a reference to a file has been acquired (for example, the file or directory is concurrently locked by another application).|
||12||The file or directory with the same path already exists.|
||10||Either there's not enough remaining storage space or the storage quota was reached and the user declined to give more space to the database. To ask for more storage, see Managing HTML5 Offline Storage.|
Access to the files were denied for one of the following reasons:
||11||The app looked up an entry, but the entry found is of the wrong type. For example, the app is asking for a directory, when the entry is really a file.|
|Feature||Chrome||Firefox (Gecko)||Internet Explorer||Opera||Safari (WebKit)|
|Basic support||13webkit||(Yes)||No support||No support||No support|
|Feature||Android||Chrome for Android||Firefox Mobile (Gecko)||IE Phone||Opera Mobile||Safari Mobile|
|Basic support||No support||0.16webkit||(Yes)||No support||No support||No support|
FileError interface has been removed starting with Gecko 13 (Firefox 13.0 / Thunderbird 13.0 / SeaMonkey 2.10). Instead the more general
DOMError interface is used and returned by