「最小抽象ファイルシステムの仕様案」の続きです。
さて、具体的な例外の種類ですが、POSIXのerrnoを拝借すればいいんじゃないでしょうか。
あーそれと、HTTPステータスコード（例えば、http://www.studyinghttp.net/status_code）も考慮したほうがいいかも。
と、例外／エラーに関する取り決めについて考えます。
POSIXのエラー番号とHTTPステータスコード
Erlangのマニュアル（http://www.erlang.org/doc/man/file.html）に列挙されているPOSIXのエラー番号は32個あるのだけど、そのなかから使いそうな17個を選んでみました。
- eacces - permission denied
- eagain - resource temporarily unavailable
- ebusy - file busy (リソースが使用中である)
- edquot - disk quota exceeded
- eexist - file already exists
- efbig - file too large
- einval - invalid argument
- eio - IO error
- eisdir - illegal operation on a directory
- enametoolong - file name too long
- enoent - no such file or directory
- enomem - not enough memory
- enospc - no space left on device
- enotdir - not a directory
- enotsup - operation not supported
- eperm - not owner
- erofs - read-only file system
一方、次のリストは、ファイルシステムのエラーと対応しそうなHTTPステータス・コードを14個抜き出したものです。（403, 410, 415は結局使ってませんが。）
- 400 Bad Request
- 401 Unauthorized
- 403 Forbidden
- 404 Not Found
- 405 Method Not Allowed
- 409 Conflict
- 410 Gone
- 413 Request Entity Too Large
- 414 Request-URI Too Long
- 415 Unsupported Media Type
- 500 Internal Server Error
- 501 Not Implemented
- 503 Service Unavailable
- 507 Insufficient Storage
ファイルシステムへの要求が失敗したとき、その結果をHTTPレスポンスに乗せて返す場合を想定して、POSIXエラー番号からHTTPステータスコードへのマップを考えてみると次のようかなー？ スタータスコードが2つ以上書いてあるところは、僕がどれか判断できない、またはどれもありそうだと思えるケースです。
| eacces - permission denied | 401 Unauthorized |
| eagain - resource temporarily unavailable | 503 Service Unavailable, 500 Internal Server Error |
| ebusy - file busy | 503 Service Unavailable, 500 Internal Server Error |
| edquot - disk quota exceeded | 500 Internal Server Error, 413 Request Entity Too Large, 409 Conflict, 507 Insufficient Storage |
| eexist - file already exists | 409 Conflict |
| efbig - file too large | 413 Request Entity Too Large |
| einval - invalid argument | 400 Bad Request |
| eio - IO error | 500 Internal Server Error |
| eisdir - illegal operation on a directory | 405 Method Not Allowed |
| enametoolong - file name too long | 414 Request-URI Too Long |
| enoent - no such file or directory | 404 Not Found |
| enomem - not enough memory | 413 Request Entity Too Large, 503 Service Unavailable, 500 Internal Server Error |
| enospc - no space left on device | 413 Request Entity Too Large, 503 Service Unavailable, 500 Internal Server Error, 507 Insufficient Storage |
| enotdir - not a directory | 405 Method Not Allowed |
| enotsup - operation not supported | 501 Not Implemented |
| eperm - not owner | 401 Unauthorized |
| erofs - read-only file system | 401 Unauthorized, 409 Conflict |
よくわからないところ
HTTPヘッダ名Authorizationなどを見ると、HTTP仕様では、Authentication（認証）とAuthorization（認可）がチャンと使い分けられてはいないようです。となると、401 Unauthorized も実は認証の問題で、「アクセス権限がないぞ」の意味で使うのは不適切なのかもしれません。
409 Conflict は、整合的な状態（システムの不変条件）を壊してしまうような操作を要求されたときに返すものだと思うのですが、disk quota exceeded みたいな事態に適切かどうかわかんないなー。システムのリソース不足だとも言えるし、クォータなんだから制約であり、その制約に違反したということでは整合性の破壊のような雰囲気もあります。
もともとが違った状況／前提において決められたエラー番号だから、素直にマップはできないんでしょうけどね。アクション（オペレーション）の仕様と一緒にもう一度考えてみようっと（後で）。
[追記]ブックマーク経由で id:havanaclub さんに、Amazon S3 におけるHTTPステータスコードへのマッピングについて教えて頂きました。http://docs.amazonwebservices.com/AmazonS3/latest/index.html?ErrorCodeList.html ありがとうございます。[/追記]
