エラー処理の問題。ファイルがなかったとか、壊れてたとかいう時にエラーを返すべきか、それともその場でassertこいて死ぬべきか。ぶっちゃけゲームにおいてはファイルがないなんてのは致命傷に決まっているので assertで止めた方がいい。しかし、ゲーム以外の用途(例えばサウンドをテストするためのアプリとか) に使うことだってあるわけで、壊れたデータをぶっこむ度にアプリごと落ちていては実用性に乏しい。しかしゲームに使うことだけを考えれば、ユーザがいちいちエラーになったかを確認せねばならない作りよりは問答無用に落ちた方がユーザがエラー処理コードを書かずに済むのでよほどユーザフレンドリーだ。さてどうするべきか。
http://www.page.sannet.ne.jp/hirasho/diary/diary0712.html#11p1
このへんを読んでいろいろ考えさせられた。誰かにとって使いやすいAPIが誰かにとっては使いにくいというありがちな問題なんだが具体的な事例がちゃんとわかってくれてる人は実は少ないような気がする。特にいわゆる下回りというかミドルウェア的なものばっかり担当していた人はとにかくエラー処理をアプリ側でさせようと全部返してくる。油断しているとアプリ側は「ミドルウェアのAPIをコールするコードを一行書くとそのエラー処理のコードを2画面分書かないといけない」とかそういう状況に容易になってしまう。
個人的にこの10年間の仕事はほとんどすべてこの「エラー処理とか資源の解放とかそういうのはアプリ側でちゃんとやってね」という下回りと「エラー処理コードや資源の解放がない場合もあるけど、たまにはエラー処理もちゃんとやりたいアプリ」との間を絶妙にうまくつなぐ部分を作ることだった。ファイルアクセスについてだとシングルタスク前提だったらエラーを下側で処理してしまってもまあ問題ないしアプリ側も「そんな状況は想定したくない」とか言ってるわけだが、それがマルチタスクになって他のアプリからロックされる状況が発生したり、ネットワーク越しのアクセスになってつながってないときがあったりするようになると、突然アプリ側が「そういう状況だとUIを表示したりしたい」とか言い出すので難しい。
組み込みアプリ開発でつらいのは、そういうややこしいところをWindowsがある程度やってくれているPCアプリしか作ったことのない人と、そもそもアプリを作ったことのないハード寄りの人がタッグを組んで「何がそんなに難しいんだ!!」と詰め寄ってくるところだ。
