0

私はいくつかのクラスを書いていますが、成功しないシナリオを適切に処理する方法を知りたいです。たとえば、パラメータとして $_FILES リソースの名前を受け入れるファイルアップロードクラス:

class FileUpload {
    private $file;

    public function __construct($file) {
        $this->file = $file;
    }

    public function upload() {
        if (!isset($_FILES[$this->file])) { 
            throw new Exception("Reference to non existent resource.");
        }

        if ($_FILES[$this->file]['error'] !== 0) { 
            throw new Exception("Resource indicates error.");
        }

                // All other sorts of checks here, like security checks,
                // and then finally moving of the file to it's final destination
    }
}

これは正しい形ですか？私の考えでは、開発者が FileUpload の新しいインスタンスを作成するとき、その意図はファイルをアップロードするか、アップロードされなかった理由を知ることであり、このクラスはまさにそれを提供します。また：

1) true (ファイルが適切な形式であるかどうかがテストされ、セキュリティがチェックされ、画像の場合はさらに処理される可能性があります。これで、まさに目的の場所になりました。要するに、必要なものはすべてうまくいきました)

2) 例外 (何か問題が発生しました。メッセージは正確に何を知らせているので、対処することができます。)

これで問題ない場合は、カスタム メッセージで Exception を使用するか、WrongMimeType などのすべてのカスタム例外を作成する必要がありますか?

それが問題であれば、クラスはオープンソースで誰でも利用できるので、その点からも標準化され、開発者にとって使いやすく、既存のソフトウェアに簡単にプラグインできるようにしたいと考えています。

4

1 に答える 1

1

コーディング スタイルに関する質問のように見えるので、これはおそらくcodereviewに移動する必要があります。

でも：

あなたのupload()方法はひどく設計されています。データを取得するのではなく、パラメーターを受け入れる必要があります$_FILES。外部ユーザーはそれを関数に渡す必要があります。通常、どのクラスもスーパーグローバル変数またはグローバル変数からデータを取得するべきではありません。

例外をスローする最初の理由を却下することを尊重します。:)

その後？見るコードがあまりないので、これ以上詳細を議論するのはちょっと難しいので、一般的なコメントに戻ります:

の代わりに例外を使用しないでくださいgoto。それらは、予期できなかった例外的な状態を通知する必要があります。

フォームを検証するとき、無効なフォーム データは予期できない例外的な状態ではありません。これは 2 つの通常のケースのうちの 1 つです。事実上、クラス内のフォーム データを検証しています。フォームが有効でない場合は、例外をスローしないでください。

別のこと: 例外メッセージで問題が発生したことを隠さないでください。複数の catch ステートメントでスローされたさまざまな例外クラスをキャッチできない場合、クラスの使用が非常に難しくなりますが、メッセージを確認する必要があります。

また、そのコードを他の人が使用できるようにすることについて質問しているため、名前空間、PSR-0 互換のオートローディング、および独自の例外クラスを使用してください。また、スーパーグローバルからデータを取得しないでください。

于 2013-10-13T17:44:17.450 に答える