利用しているライブラリの関数等を利用することで出るかもしれないエラーはどれくらいまで拾うべきなんだろうか。正直拾ったところでほとんど解決できないだろうものもあるし、どうにかできるとしてもそれがライブラリが隠してくれている部分の理解や操作が要求するならライブラリを使う意味が若干薄れる気がする。そんなこともあってできるだけそういうことはしたくない。
　(Javaよく知らないけど)Javaには、上層に投げるべき技術的例外と起こった場所で解決しようと試みるクライアント例外の考え方があるらしい。C++でも当てはまるかは分からないが、前者は例外で、後者は例外かif文で受け取るのがよさそうな気がする。どこかにもそんなことが書いてあったと思うが、それぞれは上層に解決を頼むか処理の再試行で解決が試みるのがよさそうな気がする。どちらも解決できないなら上層に投げ、最終的にはある処理の単位(大きい規模ではそのプログラム全体)を終了させるのが多分いいんだろう。


　ここでちょっと疑問なのが、ライブラリが使えるのを前提とするプログラムで

1. ライブラリから提供されたものがエラーを吐いたとして
2. その解決方法がどうやらライブラリによって提供されていないらしい　　なら

どんなエラーであっても上に例外を投げるべきだろうか。

　ライブラリが使える前提なんだから、とりあえずはそうすべきな気がする。しかし例えば、DxLib_Initのような初期化関数は成功したのにDrawGraphだのDrawStringだのが原因不明で解決不能のエラーを吐いた場合はどうしろというんだろう･･･。仮にそれを受け取った後の処理で出来るのはログへの吐き出しとプログラムの終了くらいで、そこからそのエラーを減らすために何が出来るかって言えばライブラリの最新があればそれに更新してみるくらいで、結局解決しないことも十分に考えられる･･･。将来にそれを解決できるようになる可能性が無いわけではないから一応は投げておくのが･･･良いんだろうか。例外は投げず返り値等でエラーは知れるようにはするが、呼び出しでは問題がありそうと言えないならそれを無視するスタンスでも良いような気がしてきた。
　ここまできて気づいたけど、実際にそれが起こってから考えるのが一番な気がする・・・。
　

参考にしたスライド

んぁあああ・・・悩みますよねぇ。
ワカリマス\(>口<)/ワカリマス　うぉおおん。悩むぉおおん。

私の場合は、ライブラリのイレギュラーなんて手には負えないのは分かっているので、
・ライブラリ作者様に速攻で通達するために、少なくとも再現に必要な事柄がわかるようにログの出力項目はモリモリにしておこう
・ユーザー様にクソゲー烙印されないために、そのエラーを回避できそうなオプションをなるべくいっぱい提供できるようしておこう

という考えですねぇ(^v^)・・・いまのところ。
スライドの29頁にも、技術的例外はフレームワークにまかせろとありますし・・・（あれ、これはまたチガウのかな。）