タグ付けされた質問 「null」

私のプログラムの一部は、データベース内の多くのテーブルと列からデータをフェッチして処理します。一部の列はである可能性がありますがnull、現在の処理コンテキストではエラーです。 これは「理論的には」発生しないはずなので、発生する場合は、不良データまたはコード内のバグを示しています。エラーの重大度は、フィールドによって異なりnullます。つまり、一部のフィールドでは処理を停止して誰かに通知する必要があり、他のフィールドでは処理を続行して誰かに通知するだけにする必要があります。 まれですが可能なnullエントリを処理するための優れたアーキテクチャまたは設計原則はありますか？ ソリューションはJavaで実装できるはずですが、問題は言語にとらわれないため、タグを使用しませんでした。 私自身が持っていたいくつかの考え： NOT NULLの使用 最も簡単なのは、データベースでNOT NULL制約を使用することです。 しかし、データの元の挿入がこの後の処理ステップよりも重要である場合はどうなりますか？そのため、挿入がnull（バグまたは何らかの正当な理由のために）テーブルに挿入される場合、挿入が失敗しないようにします。プログラムのさらに多くの部分が挿入されたデータに依存しているが、この特定の列には依存していないとしましょう。そのため、挿入ステップではなく、現在の処理ステップでエラーが発生する危険を冒したいのです。それが、NOT NULL制約を使用したくない理由です。 単純にNullPointerExceptionに依存 常にそこにあると期待しているかのようにデータを使用し（実際にそうであるはずです）、結果のNPEを適切なレベルでキャッチします（たとえば、現在のエントリの処理は停止しますが、処理全体は進行しません） ）。これは「フェイルファースト」の原則であり、私はしばしばそれを好みます。少なくともバグの場合、ログに記録されたNPEを取得します。 しかしその後、さまざまな種類の欠落データを区別する能力が失われます。たとえば、一部の欠落しているデータについては除外することができますが、他の場合は処理を停止して管理者に通知する必要があります。 null各アクセスの前に確認し、カスタム例外をスローする カスタム例外を使用すると、例外に基づいて正しいアクションを決定できるため、これは進むべき道のようです。 しかし、どこかで確認するのを忘れた場合はどうなりますか？また、私はコードを、まったくまたはほとんど期待されない（そしてビジネスロジックフローの一部ではない）nullチェックで混乱させます。 この方法を選択した場合、どのパターンがアプローチに最適ですか？ 私のアプローチについての考えやコメントは大歓迎です。また、あらゆる種類の優れたソリューション（パターン、原則、私のコードまたはモデルの優れたアーキテクチャなど）。 編集： 別の制約があります。ORMを使用してDBから永続オブジェクトへのマッピングを行うため、そのレベルでnullチェックを実行しても機能しません（nullが害を及ぼさない部分で同じオブジェクトが使用されるため）。 。これまでに提供された回答の両方がこのオプションについて言及したため、これを追加しました。

9 design-patterns  object-oriented-design  database-design  patterns-and-practices  null 

このコードは、簡略化すると次のようになります。 public class Room { public Client Client { get; set; } public long ClientId { get { return Client == null ? 0 : Client.Id; } } } public class Client { public long Id { get; set; } } 現在、3つの視点があります。 1）Clientプロパティは常に設定される必要があるため（つまりnullではない）、これは適切なコードでClient == nullあり、Id値0は偽のIDを示します（これはコードの作成者の意見です;-)） 2）が0偽の値であることを呼び出し元に依存することはできません。Idまた、 Clientプロパティを常に設定する必要exceptionがあるget場合は、Clientプロパティがnullになったときにをスローする必要があります。 3）Clientプロパティを常に設定する必要がある場合は、プロパティがたまたまnullの場合に戻りClient.Id、コードにNullRef例外をスローさせClientます。 これらのうちどれが最も正しいですか？または、4つ目の可能性はありますか？

9 c#  code-quality  null 

C＃のnull結合演算子を使用すると、コードを短縮できます if (_mywidget == null) return new Widget(); else return _mywidget; 至るまで： return _mywidget ?? new Widget(); C＃で使用したい便利な演算子は、オブジェクトのプロパティ、またはオブジェクトがnullの場合は他の値を返すことができる演算子であることに気づきました。交換したいので if (_mywidget == null) return 5; else return _mywidget.Length; と： return _mywidget.Length ??! 5; この演算子が存在しないのには何らかの理由があるに違いないと私は思わずにはいられません。コード臭？これを書くためのより良い方法はありますか？（私はnullオブジェクトパターンを知っていますが、これらの4行のコードを置き換えるためにそれを使用するのはやり過ぎのようです。）

9 c#  code-smell  null 

私はCSの学生として、長年にわたってまともな数のプログラミング言語を学びました。そのほとんどは、「null可能」または「オプション」タイプの概念を持っています。ここでは、nullポインターや参照、JavaScriptのような弱く型付けされた言語については触れていませんnull。私が話していることの例には、boost::optional（C ++）、java.util.Optional（Java 8.0）、prelude.Maybe（Haskell）、およびすべての「？」種類（例えばint?、float?、C＃やKotlin）。これらは、厳密な静的型システム内で、以前はnullにすることができなかった型にnullの可能性を追加する構成体です。 SQLにも同様の概念があります。たとえば、INTEGERnull可能またはnull不可にできるような型ですが、ひねりがあります。SQLでは、INTEGERデフォルトでnull可能であり、null INTEGER NOT NULL不可になるように明示的に記述する必要があります。 NULLをデフォルトの動作にすることを許可することは非常に直観に反し、潜在的に危険であると私は思います。明らかに、SQLはこの時点で非常に長い間存在しており、（ほとんどの）SQL開発者はNULLの落とし穴について健全な認識を築いています。しかし、私は仕方がないのですが、初期の頃、NULLが予期せず問題のある場所に忍び込んでいたことを想像してみてください。 SQLは私が提供したすべての例よりも古いため、これは単に歴史的な進化の問題である可能性があります。それでも、私は尋ねなければなりません、言語がこのように設計され、型がデフォルトでnull可能であるという正当な理由はありますか？ もしそうなら、それは単なる歴史的な理由でしょうか、それとも今日のデータベース設計にロジックは耐えますか？ 編集：なぜNULLがSQLの一部であるのか、またはNULL可能列がなぜ有用なのかは尋ねていません。列がデフォルトで null可能である理由を尋ねています。たとえば、次のように書くのはなぜですか。 column1 FLOAT, column2 FLOAT NOT NULL のではなく： column1 FLOAT NULLABLE, column2 FLOAT

8 sql  language-design  null 

私が持っているWifiComponent私にはCamera私のクライアントアプリケーションで。カメラのWifi関連の機能を処理します。Cameraは実際のカメラを表します。 これWifiComponentは、有効にすることができます（この場合、接続ステータスのチェックやスキャンなど、それを使って行うことができます）または無効にすることができます（この場合、有効かどうかを確認する以外は、何もできません）。 作成するときCamera、私の中のクライアントアプリケーションを、私はそのかどうかを尋ねるカメラWifiComponent有効になっています。次にWifiComponent、WifiComponentImplまたはの適切なサブクラスを作成しますNullWifiComponent。 supportedWifiTypes()およびwifiScan()メソッドの実装は簡単です。NullWifiComponent任意の種類をサポートしていない、すぐには結果をスキャンしないと発見して行われます。 しかし今、私はbool connect(WifiNetwork network, String password)メソッドを実装する必要があります。接続に失敗したと言いたいのですが...でWifiEncryptionType提供されているものもサポートしていませんWifiNetwork。実際の実装ではIllegalArgumentException、サポートされていないWifiEncryptionTypewifiネットワークを渡すとスローされます。 私は... リクエストをIllegalArgumentExceptionサポートしていないため、スローWifiEncryptionTypeしますか？ return false何が提供されていても、接続に失敗します（）。 一般的な質問： 実際の実装が契約を満たし、この契約の一部が特定の入力に対して例外をスローすることである場合、null実装はその中立性または契約を優先する必要がありますか？

8 design  design-patterns  null