tl;dr - 非常に厳格な環境で作業しているときに PHP のエラー報告レベルを管理する効果的な方法はありますか?
大丈夫; まず、「エラー抑制」が解決策になるとは思いません。私 (私は合理的に確信しています) は、エラー抑制演算子を使用したことがなく、使用する@
つもりもありません。私はset_error_handler()
and ErrorException
(または の何らかの派生error_reporting(-1)
) を利用し、 (将来の証明E_ALL | E_STRICT
)で開発します
今、私はこれらの習慣を変えたくありません。なぜなら、それらは素晴らしい習慣だと思うからです (また、私の開発/生産環境の設定/実践をさらに改善するための提案があれば、私はすべて耳を傾けます)
ただし、ビューの生成に関しては、これは少し面倒です。何らかの理由でコントローラーが特定のデータをビューに渡すことができない場合、正しいデータ (配列インデックス、変数など) が常に利用できるとは限りません。このデータがビューの生成に重要でない限り、ビューは引き続きレンダリングされます。
冗長ではありませんが(私は思う)非常に理解しやすいので、私はむしろこの構文が好きです:
// e() is a shortcut function; given the passed value evaluates to a boolean true
// it will echo() and return true, otherwise it simply returns false
<p><?php e($data['field']) or e('No data found'); ?></p>
もちろん、インデックスがない状態で が$data['field']
呼び出さoffsetGet()
れていない場合は、問題があります。null
例外を満たす、例外を満たすスクリプトの失敗に注意してください。
ノードのようなクラスを使用してデータ ツリーを作成し、ビューに渡されるデータのリスト/行を管理するなど、さまざまな実装を試しました。__get()
実際には存在しないノードを(割り当てまたはアクセス時に)作成します(ノードデータの割り当てを簡素化し、通知の発行を防ぐため。有効性についてテストされ、適切に返されますが)ノードデータにアクセスするためにも実装され、単純に欠落しているインデックスを返します。__isset()
false
ArrayAccess
null
PHP の魔法のオーバーヘッドのために、この実装を放棄することにしました (ただし、リファクタリング/最適化とプロファイリングについては多くのことを学びました) 。
代わりにネイティブ配列を使用しましたが、現在、私のビューのコードベースには が散らばっていますisset()
。率直に言って、それはただイライラするだけです (前述の実装のパフォーマンス損失よりもほとんど多く) 。
今、最も簡単な修正はerror_reporting()
、スクリプト内の位置に基づいてノッチを上下にスライドさせることだと考えていました。
// View::render()
public function render($data){
error_reporting(E_ALL & ~E_NOTICE);
// view generation logic
error_reporting(-1);
}
しかし、それは最もクリーンな (または最も安全な) 修正とは思えません。特にヘルパー関数がビュー内で呼び出される場合。私は一種の HMVC アプローチを採用しており、サブリクエストはビューから発行できるため、すべてのrender()
エスケープポイントを見つけて で保護する必要がありますerror_reporting(-1)
。
他に選択肢はありますか?