5

jslint/jshint が気に入らないことは知っていますが、次のようなことを行うことに実際の問題があるかどうかを知りたかったのです。

var err = function(msg) { throw new Error(msg); };

例 1:代入

var foo = bar.foo || baz.foo || err('missing foo property');

例 2:検証

typeof foo['bar'] !== 'string' && err('bar has to be a string');

私が知っておくべき落とし穴はありますか？

4

5 に答える 5

2

コメントで説明されているように、前述の論理演算子の原動力である真実性に対する JavaScript の緩やかな解釈により、予期しない動作が発生する可能性が高くなります。そのため、ショート サーキット アプローチが役立つ条件のサブセットは限られているため、一貫したソリューションは提供されません。

与えられた 2 つの例のうち、例 2 は、非常に定義された出力を持つテストの読みやすいアプリケーションであるため、優れたアプリケーションです。ただし、例 1 では、試行された値のいずれかがプログラム ロジックで有効である可能性があるものに評価された場合に問題が発生しますがfalse、言語の観点からは問題が発生します。このようなタイプの問題に解決策を適用すると、構文が提供できる利点が事実上打ち消されてしまいます。この種の問題のバリエーションに対する解決策は一貫していない可能性があるため、最初の作成時またはその後の変更時にバグが発生するリスクが高くなります。

于 2012-11-01T18:18:29.710 に答える
1

さて、あなたが特にタイプがであるかどうかをチェックしているならstring、あなたは大きなポイントを逃しています。生の型文字列にはメソッドがありません。

var s = 'something';
console.log(typeof s);// outputs string

var s = new String('something');// same text as above
console.log(typeof s);//outputs object

JavaScriptには、自動ボクシングと呼ばれる機能があります。最初の方法で宣言された変数に対して文字列メソッドを呼び出すと、文字列からオブジェクト文字列に自動的に切り替わるため、文字列をチェックする適切な方法は次のとおりです。

isString = function (obj) { return toString.call(obj) === '[object String]';};

Triple equal（===）は、未定義/nullのケースと一般的な比較の落とし穴をすばやく回避するために使用されます。

それ以外は大丈夫です。本番環境では、それに応じてエラーをログに記録し、throw関数を呼び出すときにtrycatchブロックを使用する必要があります。

于 2012-11-01T16:55:01.697 に答える
1

質問で示した方法を短絡することは絶対に問題なく、精巧なif-elseステートメントよりも優先されます（もちろん、チェックしている主な条件は最初に正しいはずですが、それはここのトピックではありません）。より洗練されたコードに加えて、クライアントがダウンロードする必要がある総データから本質的にバイトを削っています。これは常に良いことです。

于 2012-11-01T16:59:30.167 に答える