こんにちわ、PHPエンジニアのエンジニア婦人（@naho_osada）です。
PHPエンジニアとして9年～の経験があります。
プログラムやっていると、ファイルを読み込んだり書き込んだりする機会も多く出てきます。
設置プログラムと同じところ、すなわり同じサーバー内部でやるのであればそれほど問題は起こりません。ですが、外のファイルを読みに行くとなると別です。
allow_url_fopenが使えるかどうかという前提条件もありますが、
そもそも、外部ファイルがないことを考慮した書き方をしましょう。
なぜ、その考慮が必要なのか？
「ファイルがない」を考慮していないとすごくダサいことになる
即対応するほどのバグではないけど、なんにせよダサい。サイト上にWarningとかダサすぎる。
これに尽きます。
可能な限り起こりうるパターンを考慮してプログラムを組まないと、サイト表示が…。
公開中サイトなんだからPHPエラー表示オフ設定にすればいいじゃん、ということもありますが、その場合はひたすらエラーログが溜まるからよろしくないです。
あることが前提だけで書くな。ないことも想定して。
この場合、fileで読みに行った外部ファイルがないと
「ファイルないから読み込めないんだけど！」
というWarningが起きます。それがサイト上に出てしまうとものすごください。ださいにもほどがある。
抑制する書き方もありますが（頭に@をつけるとエラー抑制できます）そもそも抑制しないでちゃんと処理を書いてください。
変なWarningがあって色々探していたら、過去に誰かが書いたプログラムが原因だったという悲しさ。
ちゃんと修正しないとね。
教訓というか胸に留めておけっていう
NoticeとWatningが出るプログラムは書かないこと！！！
PHPのバージョンアップによって、過去バージョンではNoticeもWarningも出なかったのに、新バージョンでは出るようになりました、というのはよくあります。関数が非推奨になったとかね。
その場合はそれに対応するように改修すればいいんです（改修できないからエラー抑制することもないわけではありませんが、本来好ましくない）。
初めからエラーが出てるのに放置する、例外パターンを考えないで組むのが論外なんです。
例えば、ボールペンを売るとして、そのボールペンがよく見ると少し曲がっていて、ある角度で書くと軋むとしましょう。
普通、不良品として差し戻しされますよね。
店舗に出て売られたとしても、不良品だからと交換になりますよね。
交換数が多いと恥ずかしいですよね。自主回収になりそう
そうならないように、製造業界の方々は品質チェックしていますよね。だってそんなものが世に出たら恥ずかしいもの（あと交換差し戻しも手間、材料も勿体ない）
プログラムも同じです。
目に見える材料はありませんが、エラーがあると動かすための燃料＝サーバーの容量を食います。※エラーログが記載される設定の場合、普通は記録されるんじゃないかな
相手方がバグに気づいて修正要求してきたら交換＝バグ対応になりますね。
そんなもの世に公開しちゃったら恥ずかしいですよね。
レアケースでしか発生しないバグについてはテスト漏れしても致し方ない部分もあります。プログラムにバグは付き物ですからね。
でも、当然想定される範囲でバグを出すってどういうことよ？手抜きもいいとこじゃない？
ということです。
先のボールペンなら、ちょっと曲がっていたら書きにくい。当然想定できますよね。
うまく伝わったかわかりませんが、とにかく
「想定できるものは必ず対応せよ」
ということです。
この例なら、ファイル読み込めなかったらどうする？っていうのは当然予想して書いておくべきことです。
