問題タブ [null-check]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - MVC ビュー モデルによってスローされる NullReferenceException
私はこの問題を解決しようとしていますが、私が進んでいくにつれて多くのことを学んでいるので、誰かが私がどこで間違っているのか、および/または私が読むことができるいくつかの良いリソースを説明してくれると本当に感謝しています.上。
したがって、データベースの Entity Framework モデルに基づくモデルと、そのモデルのプロパティを表すビューモデルがあります。データ (js ファイルで定義) を表示する剣道グリッドを構築し、コントローラーのメソッドが Json 結果セットを返します。問題は、結合された db テーブルに値を表示しようとすると、キー値が設定されていない場合、nullreferenceexception エラーが発生することです。明らかに、これが起こらないようにコーディングする方法が必要なので、ここでパズルの一部が欠けています。どんな助けでもありがたく受け取られます!
私のモデルは次のようなものです:
私のコントローラーメソッドは次のようになります。
そして私のビューモデルはこれが好きです:
c# - C# で発生するイベントは常に null チェックで保護する必要がありますか?
この状況は私にとって非常に興味深いものに思えます。
C# では、イベントを発生させる前に、クラスにイベントのリスナーがあるかどうかを確認する必要があります。
C# のイベント構造は、使いやすさのために、Observer オブザーバブル パターンの非標準 (Microsoft が行ったことを意味する) 実装であると仮定します。
なぜ彼らはその構造の中でこれを実装しなかったのですか? この選択について確固たる理由や文書はありますか。
null チェックを行う必要があるのか、それとも、すべての状況で null チェックを必要とするイベント構造についての私の仮定が間違っているのでしょうか。
これは、Microsoft によるこの実装の選択に対する答えを探す好奇心に満ちた質問です。これにより、デリゲートとイベント キーワードの内部構造の理解が深まると思います。
java - マップで null チェックを行うと、アプリケーションの全体的なパフォーマンスが低下するのはなぜですか?
CountDownLatch
以下は、これらのマップで書き込みが発生するたびに、プライマリ、セカンダリ、およびターシャリ マップで初めて読み取りが発生しないようにするために使用するクラスです。
以下は、3 つのマップすべての設定のみを担当するバックグラウンド スレッド クラスです(以下の parseResponse メソッドを探してください)。10分おきに運行しています。
問題文:
マッピング オブジェクトとプライマリ、セカンダリ、およびターシャリ マップに対してあらゆる種類の null チェックまたはサニティ チェックを実行すると、パフォーマンスが大幅に低下します (理由は不明です)。しかし、健全性チェックや null チェックを行わなければ、パフォーマンスは非常に良くなります。誰が何が間違っているのか、なぜそれが起こるのか説明できますか?
以下は例です -
ClientData
メインスレッドですべてのマッピングを取得するためにクラスを使用しています。mappings
以下に示すように、 、mappings.primary
、mappings.secondary
およびmappings.tertiary
が空でないことを確認するために、あらゆる種類の健全性チェックを行っています。それらが空の場合、エラーをログに記録して戻ります
1 次、2 次、および 3 次マッピングに対する上記のサニティーおよびヌル・チェックにより、アプリケーションの全体的なパフォーマンス (95 パーセンタイル) は 4 ミリ秒になります。
しかし、1 次、2 次、および 3 次マッピングのサニティー・チェックまたはヌル・チェックなしでこのようにすると、全体的なパフォーマンス (95 パーセンタイル) は 0.87 ミリ秒になります。
以下は私の isEmpty と isNotEmpty メソッドです -
syntax - nullチェックをGroovy化する方法は?
このGroovyコードを書くためのより「Groovy」な方法はありますか?
ロジックは次のとおりです。
- が NULL の場合
System.getProperty("props")
、NULL になりたいですprops
。 props
そうでなければ、私はの値になりたいSystem.getProperty("props")
c# - 返品にアイテムが含まれているかどうかを確認する
次のようなルーチンを最適化しようとしています (簡略化):
呼び出すメソッドは次のGetBars()
ようになります
GetBaz()
0 から多数のアイテムを返します。数百万の ID をif(bars.Any())
処理したため、アプリケーションを高速化するための最初の試みとしてステートメントを最初に追加しました。
は待機中なので、GetBars()
すべてのデータを収集するまでスレッドをブロックします (時間がかかる場合があります)。if(bars.Any())
私のアイデアは、yield return を使用してから、少なくとも 1 つの要素を取得したかどうかをテストするチェックに置き換えて、その間に他の 2 つの非同期メソッドを起動できるようにすることでした (これも実行に時間がかかります)。
私の質問は、これを行う方法です。私は利回りリターンの全体的なアイデアを知っSystem.Linq.Count()
てSystem.Linq.Any()
いて無効にし、列挙可能な最初の項目をチェックすると、列挙可能なものから削除されます。
たとえば、 out パラメータをに追加する以外に、別の/より良いオプションはありますGetBars()
か?
TL;DR: 反復を開始せずに、yield リターンからの列挙型にオブジェクトが含まれているかどうかを確認するにはどうすればよいですか?
java - 7 と 8 の間の Eclipse 互換性ブレークでの Null 分析
Oracle Java 8u25 を使用した Windows 7 64 ビットで、Spring ツール スイート 3.6.2 (Eclipse クローン) で nullcheck 分析の奇妙な動作に遭遇しました。Java 7 ソース互換性を持つ同じ Maven プロジェクトは、Eclipse で NPE エラーを正常に検出しますが、Maven のコンパイル バージョンを Java 1.8 に変更すると、Eclipse はこのエラーを検出できません。
Eclipse での私の nullcheck 分析構成 (Java->Compiler->Errors/Warnings->Null 分析) は次のとおりです。 (Java 7で動作するため、すべて問題ないようです)
私のmaven pomはここにありますhttp://pastebin.com/pF1yJSG2、上記のように、pomのjava.versionが1.7の場合はnullチェックが機能し、1.8の場合はnullチェックが機能しません。
サンプル ソース コードは次のとおりです。
どこに問題があり、nullcheck を jdk 1.8 互換性の下で動作させる方法を知っている人はいますか?
編集: Maven は関与していないようです。同じソースコードとコンパイラの互換性レベルが1.7に設定された非mavenプロジェクトで同じ問題がシミュレートされました。バグですか?
EDITED-2:さらに調査した結果、注釈の次の違いが違いを生むことがわかりました: java.lang.annotation.ElementType.TYPE_USE 、注釈にこれがない場合、Java 8ではnullcheckは検出されませんが、Javaでは検出されます7.しかし、なぜですか?なぜそんなに異なる動作があるのですか?!
EDITED-3: MartinLippert からの調査と私がテストした結果、nullcheck API は Java 7 と Java 8 の間で大幅に変更されたようです。null 検出には (Eclipse ライブラリのバージョン 2.0 から見られるように) java.lang.annotation.ElementType.TYPE_USE が必要です。タイプ @Target(value={METHOD,FIELD,ANNOTATION_TYPE,CONSTRUCTOR,PARAMETER}) は分析では無視されます。質問は次のとおりです。Java 8 で NULL 分析が必要であり、新しい要素タイプでのみ機能するのはなぜですか? (Java 8 では新しい言語機能を十分に活用するのが良いことは理解していますが、なぜ互換性を壊す必要があったのでしょうか?たとえば、javax.validation @NotNull は nullchecking アノテーションとして使用できなくなりました :-((( )