4

「TypeError: エラー #1009: null オブジェクト参照のプロパティまたはメソッドにアクセスできません」を防ぐために、静的解析を使用したいと考えています。

私の知る限り、@NotNull/@Nullable を使用する Java 用の静的アナライザーがあります。プログラマーは、すべてのメンバー/関数/引数にこれらの注釈を指定することで意図を明示的に表現し、ツールがすべてが正しく、すべての @Nullable -> @NotNull 変換が null のチェックで行われるかどうかを確認できるようにします。私にとっては、 @Nullable のみを指定して、他のすべてを @NotNull のように処理できるようにする方が快適ですが、必須ではありません。

Actionscript 3 用のその種の無料ツールがあるのだろうか?

私は FlashBuilder 4.5 のライセンスを持っていますが、それ以上は購入したくありません。IntelliJ IDEA にはそのような機能があるかもしれないと聞きましたが、無料ではない Ultimate Edition の Actionscript でのみ機能します :(

質問は次のとおりです。

  1. Actionscript 3 用の静的アナライザーはありますか?
  2. 無料じゃないといくらかかるの？
  3. 「すべてをチェックしてコードを混乱させる」以外に、1009エラーを防ぐための他の解決策はありますか。

アップデート

与えられた完全な答えはありません:(しかし、weltraumpiratの答えはこれまでのところ最高です。私はnull可能な関数に命名規則を使用することを検討しています：Try *、Find *、* OrNull、* IfAnyなど。名前は長くなりますが、信頼性はより重要ですありがとうございます weltraumpirat! 報奨金はあなたのものですが、回答がいっぱいではないため、回答を「承認済み」としてマークしません。

4

5 に答える 5

6

私の知る限り、null 参照エラーを実際に防止できる ActionScript 用の静的分析ツールはありません。ツール、さらに言えば) を確認できます。

ただし、できることとすべきことは、そもそもnull 参照を防止し、意味のあるエラー メッセージを表示してエラーをより迅速に発見できるようにコードを設計することです。

次のように考えてみてください:変数インスタンスが特定の時点で null であってはならない場合、プログラムはとにかく実行を許可されるべきでしょうか? ほとんどの場合、答えは明確です。いいえ、すべきではありません。

たとえば、null 参照を防止する代わりに、次のように、プログラム内の考えられるすべてのポイントに null チェックを追加するというよくある間違いがあります。

function myMethod( something:* ) : void {
    if ( something != null) {
       doStuff();
    }
}

この結果、エラーがスローされるのではなく (問題を追跡するために、クラッシュが発生したメソッドの名前と行番号を見つけることができます)、プログラムは実行され続けますが、何も起こりません。起こります。手動テストを実行すると、次のように表示されます。そして、何がうまくいかなかったのかを示すものはありません。

null 参照を処理するより良い方法は、

  • どのメソッドも null を返さないようにしてください。 今まで。

    これは、次のようなデフォルト値を返すことで実現できます。

    function getPropertyValue() : String { 
    return _property != null ? _property : "";
}

    もちろん、デフォルト値は などの意味のあるものにすることができます"Property did not have a value."。そうすれば、プログラムの残りの部分を損なうことなく、UI ですぐに問題に気付くことができます。(これは getter だけでなく、値を返すすべてのメソッドで機能することに注意してください - 私は単純に明白な例を選びました。)

    なんらかの理由で本当に null を返すことを回避できない場合は、メソッド名がそれを反映していることを確認してください。そうすれば、それを使用するときに、可能な null 値を期待できることがわかります。

     function getPropertyValueOrNull() : String {
     return _property;
 }

  • 無駄な null チェックの代わりに、アプリケーションの重要なポイントで検証メソッドを作成し、意味のあるエラーをスローして問題の原因を指摘します。

    function tryExecuteImportantFunction() : void {
    try {
         validate();
         executeImportantFunction();
    } catch ( e:Error ) {
         trace( "Validation failed:" + e.message );
    }
}

function validate() : void {
    if (_requiredProperty1 == null) 
        throw new Error ( "_requiredProperty1 was null, but should always contain a string value.");
    if (_requiredProperty2 == null) 
        throw new Error ( "_requiredProperty2 was null, but should always contain a dictionary.");
}

    意味のあるエラーはキャッチしてログまたはデバッグ コンソールに転送する必要があります。これにより、原因を探す場所が常にわかり、修正するために何をする必要があるかがわかります。

于 2012-05-26T12:05:26.697 に答える
0

FlexPMDを試してみることもできます。これはJavaのPMDと密接に関連しており、ルールを適用することでソースコードのにおいを見つけます。

アドビはそれをオープンソースとしてリリースしました。sourceforgeで入手できます：http ：//sourceforge.net/adobe/flexpmd/home/Home/

ここに小さな紹介ビデオがあります：http：//www.riagora.com/2010/04/introduction-to-flex-pmd/

私の知る限り、Flex Builderと簡単に統合できますが、IntelliJやFDTなどの他のIDEやコマンドラインでも機能するはずです。

于 2012-06-01T04:41:03.697 に答える
0

この場合、getter と setter が最も便利です。

protected var _value:Object;

public function get value():Object{
    if(_value){
        return _value;
    }
    trace("missing object");// or throw "missing object error"
    return new Object();
}

public function set value(v:Object):void {
    _value = v;
}

編集：

また、null チェックの追加事項として、describeType() xml を読み取り、存在する場合はアクセス可能な値をチェックすることもできます。

于 2012-05-26T16:51:20.093 に答える
0

null を完全に回避する方法でプログラミングすることについて weltraumpirat が言ったことには賛成です。ただし、私の経験では、これが常に可能であるとは限りません。私たちが行った最近のプロジェクトでは、型や形状が変化する多くの動的データを取得して生成していました。

ネットワークのタイムアウト、コールバックの終了、およびその他の予期しないことが原因で、null がアプリケーションを停止させていました。Null エラーは重要ではなく、多くのシナリオで予想されることはわかっていました。

これにより、ゲーム内のすべてのエラー ケースに対して動的エラー処理が必要になりました。try catch ステートメントが遅すぎるか、多くのメンテナンスが必要でした。Flash Player は、これを処理する 1 つの方法を提供しますが、すべての問題セットに対する最適な解決策ではない場合があります。Flash Player 10.1 リリース後に導入された「UncaughtErrorEvent」です。

Flash Player UncaughtErrorEvent

さらに、これを処理できる非常に優れたライブラリがあります。ここ：

グローバル エラー ハンドラ

最後に、Flash Player 開発の将来のロードマップを見ると、プラットフォームに静的型付け、オーバーロード、および多くの大きな変更が加えられることに気付くでしょう。しかし、今のところ、それが私が使用した最良のソリューションです。

Flash Player ロードマップ

于 2012-05-29T09:23:11.200 に答える
0

GUI プログラミングの問題は、常に何らかの状態が存在することです。説明されている問題は、基本的に有効な状態と無効な状態を持っていることです。経験豊富な Flex 開発者として言えることは、無効な状態のような状態はありません。null は有効な参照であるため、対処する必要があります。

私が尋ねる最初の質問は、なぜ null が悪いのかということです。null は、物事をクリーンアップし、データのない状態のアイデアを確実に得るために必要です。

Flex には、基本的に非常に興味深い動作につながるライブ サイクルのアイデアがあります。コンポーネントが初期化されるとき、その子は初期化されません。基本的に、これは一見すると非常に壊れやすいシステムです。プロパティは、ほとんどの場合、ビューによって集約された他のコンポーネントに委任されます (ビュー レイヤーに関して)。しかし、同じことがモデル、コントローラー、またはサービス レイヤーにも発生する可能性があります。

では、その問題にどう対処するか？そもそも設計上の判断だと思います。null がシステムを壊す値と見なされる場合、デフォルトでシステムはほとんど壊れています。null は、データがないことを示す最も簡単な方法だと思います。

別のアプローチは、デフォルト モデルの作成です。私の観点からは、他のすべてのコンポーネントがモデルに依存しているため、モデルは唯一の残念な点です。

package net.icodeapps.examples.model
{
  public class User
  {
  }
}

package net.icodeapps.examples.model
{
  public class DefaultUser extends User
  {
  }
}

このようなデフォルト モデルを使用すると、null ではない有効な参照と値を使用してアプリケーションを簡単にブートストラップできますが、デフォルト モデルが処理されているかどうかにかかわらず、決定も行う必要があります。

また、ここが最も重要な部分です。システムが適切に検討されていない場合、アプリから null を追い出すと、最終的にはメモリが失われます。

于 2012-06-02T19:40:50.523 に答える