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

Nullは値がないことです。nullは通常、参照変数またはポインタ変数がメモリ内のオブジェクトを指していないことを示すために使用されます。

22
null参照は本当に悪いことですか?
プログラミング言語にnull参照を含めることは「10億ドルの間違い」だと言ったと聞きました。しかし、なぜ?確かに、それらはNullReferenceExceptionsを引き起こす可能性がありますが、それではどうでしょうか?不適切に使用すると、言語の要素がエラーの原因になる可能性があります。 そして、代替手段は何ですか?私はこれを言う代わりに: Customer c = Customer.GetByLastName("Goodman"); // returns null if not found if (c != null) { Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!"); } else { Console.WriteLine("There was no customer named Goodman. How lame!"); } あなたはこれを言うことができます: if (Customer.ExistsWithLastName("Goodman")) { Customer c = Customer.GetByLastName("Goodman") // throws error …

16
彼がヌルを期待していない場合、ヌルをチェックする必要がありますか?
先週、アプリケーションのサービスレイヤーでnullを処理することについて、激しい議論がありました。問題は.NETコンテキストにありますが、Javaや他の多くのテクノロジーでも同じです。 問題は、nullを常にチェックし、何があってもコードを動作させるか、nullが予期せず受信されたときに例外を発生させるか、ということでした。 一方で、nullを期待していない(つまり、それを処理するユーザーインターフェイスがない)ところをチェックすることは、catchを空にしてtryブロックを記述することと同じです。エラーを隠しているだけです。エラーは、コード内で何かが変更され、nullが予期される値になったこと、または他のエラーがあり、間違ったIDがメソッドに渡されたことが考えられます。 一方、nullをチェックすることは一般的に良い習慣です。さらに、チェックがある場合、アプリケーションが機能し続ける可能性がありますが、機能のごく一部が効果を発揮しません。次に、「ページXを開くことができない」などのより深刻なバグの代わりに、「コメントを削除できない」などの小さなバグを報告する場合があります。 あなたはどのような慣習に従い、どちらのアプローチに対して賛成または反対ですか? 更新: 特定のケースに関する詳細を追加します。データベースからいくつかのオブジェクトを取得し、それらに対して何らかの処理を行いました(たとえば、コレクションを構築します)。コードを記述した開発者は、オブジェクトがnullになる可能性があることを予期していなかったため、チェックを含めず、ページが読み込まれたときにエラーが発生し、ページ全体が読み込まれませんでした。 明らかに、この場合はチェックが必要でした。次に、処理されるすべてのオブジェクトを、欠落していることが予想されない場合でもチェックする必要があるかどうか、および最終的な処理をサイレントに中止するかどうかについて議論しました。 仮想的な利点は、ページが引き続き機能することです。Stack Exchangeのさまざまなグループ(ユーザー、コメント、質問)の検索結果を考えてください。メソッドはnullをチェックし、ユーザーの処理を中止できます(バグがnullのため)が、「comments」および「questions」セクションを返します。「ユーザー」セクションが欠落することを除いて、ページは引き続き機能します(これはバグです)。早期に失敗してページ全体を壊すか、作業を続けて「ユーザー」セクションが欠落していることに誰かが気付くのを待つべきでしょうか?

10
nullが悪い場合、なぜ現代の言語はそれを実装するのですか?[閉まっている]
JavaやC#のような言語のデザイナーは、null参照の存在に関連する問題を知っていたはずです(null参照は本当に悪いことですか?を参照)。また、オプションタイプの実装は、null参照ほど複雑ではありません。 とにかくそれを含めることにしたのはなぜですか?null参照の欠如は、言語の作成者とユーザーの両方から、より良い品質のコード(特により優れたライブラリ設計)を奨励(または強制)するだろうと確信しています。 それは単に保守主義のせいなのでしょうか-「他の言語にもあります、我々もそれを持たなければなりません...」?

12
SQL:空の文字列とNULL値
私はこの主題が少し物議を醸すことを知っています、そして、インターネットの周りに浮かんでいる多くの様々な記事/意見があります。残念ながら、それらのほとんどは、その人がNULLと空の文字列の違いを知らないことを前提としています。そのため、結合/集計を使用した驚くべき結果についてのストーリーを伝え、一般にもう少し高度なSQLレッスンを行います。これを行うことで、彼らは絶対に全体のポイントを見逃し、したがって私にとって役に立たない。したがって、この質問とすべての回答が主題を少し前進させることを願っています。 個人情報(名前、生年月日など)を含むテーブルがあり、列の1つがvarchar型の電子メールアドレスであるとします。何らかの理由で、一部の人々は電子メールアドレスを提供したくないかもしれません。このようなデータ(電子メールなし)をテーブルに挿入する場合、2つの選択肢があります。セルをNULLに設定するか、空の文字列( '')に設定します。あるソリューションを別のソリューションよりも選択することの技術的な影響をすべて把握しており、どちらのシナリオでも正しいSQLクエリを作成できると仮定します。問題は、両方の値が技術レベルで異なっていても、論理レベルでまったく同じであることです。NULLと ''を見た後、私はただ一つの結論に達しました:その男のメールアドレスがわかりません。どんなに頑張っても NULLまたは空の文字列を使用して電子メールを送信できなかったため、明らかにほとんどのSMTPサーバーは私のロジックに同意します。そのため、値がわからない場合はNULLを使用する傾向があり、空の文字列は悪いことだと考えます。 同僚との激しい議論の後、2つの質問がありました。 不明な値に空の文字列を使用すると、データベースが事実について「嘘をつく」ことになりますか?もっと正確に言うと、何が価値で何がそうでないのかというSQLの考えを使用して、結論が出るかもしれません。しかし、その後、電子メールを送信しようとすると、矛盾した結論に達します。いいえ、電子メールアドレスがないため、@!#$データベースは嘘をついているはずです。 空の文字列 ''が重要な情報(値と値なし以外)の非常に優れたキャリアになる可能性のある論理的なシナリオはありますか?空の文字列を実際の値やNULLと一緒に使用するのが良い場合があると主張する多くの投稿を見てきましたが、これまでのところ(SQL / DB設計の観点から)論理的なシナリオは見ていません。 PS一部の人々は、個人的な好みの問題であると答えたいと思うでしょう。私は同意しません。私にとって、それは重要な結果を伴う設計上の決定です。だから、これについての意見がいくつかの論理的および/または技術的理由によって裏付けられている答えを見てみたい。
72 design  database  sql  strings  null 

7
Nullという姓は、多くのデータベースでどのように問題を引き起こしますか?
BBC に関する記事を読みました。彼らが言った例の1つは、姓が「Null」の人が一部のウェブサイトに詳細を入力するのに問題があるということでした。 彼らが直面しているエラーについての説明はありません。 しかし、私が知る限り、文字列 'Null'と実際のNull値は完全に異なります(データベースの観点から)。 これがデータベースで問題を引き起こすのはなぜですか?
71 database  null 

24
NULLとゼロの違いを説明するにはどうすればよいですか?
パーセント変化式を使用する問題に取り組んでいます: percent change = 100 * [(new value - old value) / old value] プログラマーではないかもしれない誰かにではnew value or old value = NULLなく、ifの違いをどのように説明し0ますか? 上司は、値ではなく空の文字列がTextBoxにある理由を疑問に思っています。これは、新しい値ではなく古い値があるためです。
59 null  tsql 

5
nullではなくMaybe型の言語はエッジ条件をどのように処理しますか?
Eric Lippertは、C#が型nullではなくaを使用する理由についての彼の議論でMaybe<T>非常に興味深い点を述べました。 型システムの一貫性が重要です。null不可の参照が無効であると判断された状況下では決してないことを常に知ることができますか?参照型のnull不可フィールドを持つオブジェクトのコンストラクターではどうでしょうか?そのようなオブジェクトのファイナライザでは、参照を埋めるはずのコードが例外をスローしたためにオブジェクトがファイナライズされますが、どうでしょうか?その保証についてあなたに嘘をついている型システムは危険です。 それは少し驚くべきものでした。関連する概念に興味があり、コンパイラや型システムをいじくり回しましたが、そのシナリオについては考えませんでした。nullの代わりにMaybe型を持つ言語は、初期化やエラー回復など、想定される非null参照が実際には有効な状態にないエッジケースをどのように処理しますか?

8
値が有意に欠落している可能性がある場合、null参照よりも新しいブールフィールドの方が良いですか?
たとえばMember、lastChangePasswordTimeを持つクラスがあるとします。 class Member{ . . . constructor(){ this.lastChangePasswordTime=null, } } 一部のメンバーはパスワードを変更できないため、lastChangePasswordTimeには意味がない場合があります。 しかし、nullが悪である場合、値が有意に欠落する可能性がある場合は何を使用する必要がありますか?およびhttps://softwareengineering.stackexchange.com/a/12836/248528の場合、nullを使用して意味のない値を表すべきではありません。だから私はブールフラグを追加しようとします: class Member{ . . . constructor(){ this.isPasswordChanged=false, this.lastChangePasswordTime=null, } } しかし、私はそれがかなり時代遅れだと思います: isPasswordChangedがfalseの場合、lastChangePasswordTimeはnullでなければならず、lastChangePasswordTime == nullのチェックはisPasswordChangedのチェックとfalseがほぼ同じなので、lastChangePasswordTime == nullを直接チェックすることをお勧めします。 ここでロジックを変更すると、両方のフィールドの更新を忘れることがあります。 注:ユーザーがパスワードを変更すると、次のように時間を記録します。 this.lastChangePasswordTime=Date.now(); 追加のブールフィールドは、ここでnull参照よりも優れていますか?
39 null  boolean 

4
null値はどこに保存されますか、それともまったく保存されますか?
null値またはnull参照について学びたいです。 たとえば、Appleというクラスがあり、そのインスタンスを作成しました。 Apple myApple = new Apple("yummy"); // The data is stored in memory それから私はそのリンゴを食べました、そして今、それはヌルである必要があるので、それをヌルとして設定します。 myApple = null; この電話の後、私はそれを食べたことを忘れてしまったので、確認したいと思います。 bool isEaten = (myApple == null); この呼び出しで、myAppleはどこを参照していますか?nullは特別なポインター値ですか?その場合、1000個のnullオブジェクトがある場合、ポインター型をintと見なすと、1000個のオブジェクトメモリスペースまたは1000個のintメモリスペースを占有しますか?
39 memory  null 

7
なぜ「オブジェクト参照がオブジェクトのインスタンスに設定されていない」とどのオブジェクトがわからないのですか?
私たちはシステムを立ち上げており、時々NullReferenceExceptionメッセージで有名な例外を受け取りますObject reference not set to an instance of an object。 しかし、ほぼ20個のオブジェクトがあるメソッドでは、オブジェクトがnullであると言うログを持つことは、まったく役に立ちません。あなたがセミナーの警備員であるとき、100人の出席者のうちの1人がテロリストであるとあなたに言うようなものです。それは本当にあなたにはまったく役に立ちません。どの男が脅迫的な男であるかを検出したい場合は、より多くの情報を取得する必要があります。 同様に、バグを削除する場合は、どのオブジェクトがnullであるかを知る必要があります。 今、何かが私の心を数ヶ月の間取りつづけています、そしてそれは: なぜ.NETから名前、または少なくともオブジェクト参照のタイプが提供されないのですか?。リフレクションまたは他のソースからタイプを理解できませんか? また、どのオブジェクトがnullであるかを理解するためのベストプラクティスは何ですか?これらのコンテキスト内のオブジェクトのNULL可能性を常に手動でテストし、結果をログに記録する必要がありますか?もっと良い方法はありますか? 更新: 例外The system cannot find the file specifiedは同じ性質を持っています。プロセスにアタッチしてデバッグするまで、どのファイルを見つけることができません。これらのタイプの例外はよりインテリジェントになる可能性があると思います。.NETがc:\temp.txt doesn't exist.その一般的なメッセージの代わりに私たちに伝えることができたらもっと良いと思いませんか?開発者として、私は賛成票を投じます。

7
メソッドが不正な入力を返すことができないことがわかっている場合でも、メソッド呼び出しの戻り値を検証する必要がありますか?
呼び出しているメソッドがそのような期待を満たしているとわかっていても、メソッドが呼び出した期待値を満たしていることを検証することで、メソッド呼び出しの戻り値に対して防御する必要があるかどうか疑問に思っています。 与えられた User getUser(Int id) { User temp = new User(id); temp.setName("John"); return temp; } 私はすべき void myMethod() { User user = getUser(1234); System.out.println(user.getName()); } または void myMethod() { User user = getUser(1234); // Validating Preconditions.checkNotNull(user, "User can not be null."); Preconditions.checkNotNull(user.getName(), "User's name can not be null."); System.out.println(user.getName()); } …

9
ほとんどの「よく知られた」命令型/オブジェクト指向言語が、「何もない」値を表すことができる型への未チェックのアクセスを許可するのはなぜですか?
null(たとえば)の代わりに持つことの(不)利便性について読んでいMaybeます。この記事を読んだ後、私はそれを使用する方がはるかに良いと確信していますMaybe(または同様のもの)。しかし、すべての「よく知られた」命令型またはオブジェクト指向プログラミング言語がまだ使用しておりnull(「何もしない」値を表すことができる型への未チェックのアクセスを許可します)、そしてMaybeほとんどが関数型プログラミング言語で使用されていることに驚いています。 例として、次のC#コードを見てください。 void doSomething(string username) { // Check that username is not null // Do something } ここで何か悪臭がします...引数がnullかどうかを確認する必要があるのはなぜですか?すべての変数にオブジェクトへの参照が含まれると仮定すべきではありませんか?ご覧のとおり、問題は、定義上、ほとんどすべての変数にnull参照が含まれている可能性があることです。どの変数が「null可能」で、どれがそうでないかを判断できたらどうでしょうか。これにより、デバッグと「NullReferenceException」の検索中に多くの労力を節約できます。デフォルトでは、null参照を含むことができる型はないことを想像してください。その代わりに、本当に必要な場合にのみ、変数にnull参照を含めることができると明示的に述べます。それが多分背後にある考え方です。場合によっては失敗する関数(ゼロ除算など)がある場合は、Maybe<int>、結果がintである可能性があることを明示的に示しますが、何もありません!これは、nullではなくMaybeを好む理由の1つです。他の例に興味がある場合は、この記事を読むことをお勧めします。 事実は、ほとんどの型をデフォルトでNULL可能にするという欠点にもかかわらず、ほとんどのオブジェクト指向プログラミング言語は実際にそれをNULL可能にします。それが私が疑問に思う理由です: nullプログラミング言語ではなく、どのような引数を実装する必要がありMaybeますか?理由はありますか、それとも単に「歴史的な荷物」ですか? この質問に答える前に、nullとMaybeの違いを理解してください。

6
ヌルポインターとヌルオブジェクトパターン
帰属:これは関連するP.SEの質問から生まれました 私のバックグラウンドはC / C ++ですが、Javaでかなりの仕事をしており、現在C#をコーディングしています。私のCのバックグラウンドのために、渡されたポインターと返されたポインターのチェックは間接的ですが、私はそれが私の視点にバイアスをかけることを認めています。 私は最近、オブジェクトが常に返されるという考え方のNull Object Patternの言及を見ました。通常の場合は、予想されるデータが設定されたオブジェクトを返し、エラーの場合は、nullポインターの代わりに空のオブジェクトを返します。呼び出し元の関数には常にアクセスするオブジェクトがあるため、NULLアクセスメモリ違反を回避するという前提があります。 それでは、Null Object Patternを使用する場合とNullチェックを行う場合の長所と短所は何ですか? NOPを使用すると、よりクリーンな呼び出しコードを見ることができますが、それ以外の場合には発生しない隠れた障害がどこで発生するかを確認することもできます。サイレントミスが野生に逃げるのではなく、開発中にアプリケーションをハードに失敗させます(別名例外)。 Null Object Patternには、nullチェックを実行しないのと同様の問題はありませんか? 私が扱ったオブジェクトの多くは、独自のオブジェクトまたはコンテナを保持しています。メインオブジェクトのすべてのコンテナに独自の空のオブジェクトがあることを保証するために、特別なケースが必要になるようです。ネストの複数の層でこれがwithいように思える。

7
ArgumentNullExceptionのスローはどのように役立ちますか?
メソッドがあるとしましょう: public void DoSomething(ISomeInterface someObject) { if(someObject == null) throw new ArgumentNullException("someObject"); someObject.DoThisOrThat(); } を投げることArgumentNullExceptionは「正しい」と信じるように訓練されていますが、「オブジェクト参照がオブジェクトのインスタンスに設定されていません」エラーはバグがあることを意味します。 どうして? 参照をキャッシュsomeObjectして後で使用する場合は、渡されたときに無効性をチェックし、早期に失敗する方が良いことを知っています。ただし、次の行でそれを間接参照している場合、なぜチェックを行うことになっていますか?何らかの方法で例外をスローします。 編集: それはちょうど私に起こりました...逆参照されたnullの恐怖は、あなたをチェックしないC ++のような言語に由来しますか?
27 c#  null 

8
nullが悪である場合、値が有意に欠落する可能性がある場合は何を使用する必要がありますか?
これは、繰り返し繰り返されている規則の1つであり、私を困惑させます。 ヌルは悪であり、可能な限り避けるべきです。 しかし、しかし-私の素朴さから、私に悲鳴を上げさせてください-時には価値が意味なく欠けていることがあります! 私が今取り組んでいるこのアンチパターンに乗った恐ろしいコードから来る例でこれを聞かせてください。これは、中核となるマルチプレイヤーウェブターンベースのゲームであり、両方のプレイヤーのターンが同時に実行されます(ポケモンのように、チェスとは逆に)。 各ターンの後に、サーバーは更新のリストをクライアント側のJSコードにブロードキャストします。更新クラス: public class GameUpdate { public Player player; // other stuff } このクラスはJSONにシリアル化され、接続されているプレーヤーに送信されます。 ほとんどのアップデートには当然プレイヤーが関連付けられています-結局のところ、どのプレイヤーがこのターンにどのプレイヤーを動かしたかを知る必要があります。ただし、一部の更新プログラムでは、意味のあるPlayerを関連付けることができません。例:アクションなしのターン制限を超えたため、ゲームは強制的に結び付けられました。このような更新では、プレーヤーを無効にすることは有意義だと思います。 もちろん、継承を利用することでこのコードを「修正」できます。 public class GameUpdate { // stuff } public class GamePlayerUpdate : GameUpdate { public Player player; // other stuff } ただし、次の2つの理由から、これがどのように改善されるかはわかりません。 JSコードは、定義されたプロパティとしてPlayerのないオブジェクトを受け取るだけです。これは、値が存在するかどうかを確認する必要があるため、nullの場合と同じです。 別のnull可能フィールドをGameUpdateクラスに追加する場合、この設計を続行するには多重継承を使用できる必要がありますが、MIはそれ自体が悪であり(経験豊富なプログラマーによると)、さらに重要なことには、C#はそうではありません持っているので使用できません。 このコードのこの部分は、経験豊富で優秀なプログラマーが恐怖で叫ぶことになる非常に多くのコードの1つであるという感想があります。同時に、この場所でこのヌルがどのように何かを傷つけているか、代わりに何をすべきかを見ることができません。 この問題について説明してもらえますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.