2016-12-07 2 views
0

私は非常に奇妙な問題を抱えています。私は製品の同期を行うアプリケーションを開発し始めました。製品リストのダウンロードは、更新中にGUIをロックしないように非同期でなければなりませんでした。私はその仕事をバックグラウンドワーカーとして選択しました。すべてが正常に機能しました。エラーが発生した場合は、RunWorkerCompletedで処理しました。BackgroundWorkerがRunWorkerCompletedに例外を渡すのを停止しました

背景労働者の1の方法は、このメソッド内からではなくからスローされDoWork内から例外がをRunWorkerCompleted、最近、私はいくつかの改良を行うように頼まれたが、今、私は大きな問題が発生しません。

.NETフレームワークの一部のアップデートが変更された可能性があります。backgroundWorker私が知りませんか?私は実際にはすべて正常に動作するまで、フレームワークのバージョンを把握していません。重要な場合は、SharpDevelop 5.1をIDEとして使用します。

私は問題についていくつかのウェブ検索を行ってきましたが、解決策のいずれかが私の問題を解決していないか、あるいは間違った方法で適用していますか?私は非デバッグモードでアプリケーションを実行する

  • を試した事がある - 何もDoWork内の例外をキャッチし、バックグラウンドワーカーをキャンセル
  • を変更していない - そして労働者が完了しましたが、エラーがRunWorkerCompletedに渡されませんでしたこれが最初で働いていた私にとって、何がそれを削除するかのようにそれを残して、間違っていなかった - それは、物事を破る必要があったとして
  • をRunWorkerCompletedの内側からe.Result.ToString()を取り払いますそれは私にはわからない

が変更され何も違いはありませんし、それを修正する方法か見当もつかない、道をエラー渡すためにBackgroundWorkerのを私の問題を解決し、を作成する方法に関しては、誰もが何か提案を持っていました。そうすべき。ここ

は私が期待通りのBackgroundWorkerが動作していることをお勧めしたい、あなたのコードを実行した問題

public string WEB_JSON_RAW_DATA {get;set;} 

    bgwProductListUpdater = new BackgroundWorker(); 
    bgwProductListUpdater.WorkerReportsProgress = true; 
    bgwProductListUpdater.DoWork += new DoWorkEventHandler(this.bgwProductListUpdaterDoWork); 
    bgwProductListUpdater.ProgressChanged += new ProgressChangedEventHandler(this.bgwProductListUpdaterProgressChanged); 
    bgwProductListUpdater.RunWorkerCompleted += new RunWorkerCompletedEventHandler(this.bgwProductListUpdaterRunWorkerCompleted); 

    void bgwProductListUpdaterDoWork(
     object sender, 
     System.ComponentModel.DoWorkEventArgs e) 
    {  
     //source of exception 
     WEB_JSON_RAW_DATA += (string)ApiClient.Get("/admin/product.json?GET_LIST"); 

     //rest of json processing 
    } 

    void bgwProductListUpdaterProgressChanged(
     object sender, 
     System.ComponentModel.ProgressChangedEventArgs e) 
    { 
     //this method is empty, it was intended to be used but then no need of progress repporting was needed 
     //it was all the time in my code so i do paste it as well 
    } 

    void bgwProductListUpdaterRunWorkerCompleted(
     object sender, 
     System.ComponentModel.RunWorkerCompletedEventArgs e) 
    { 
     if(e.Error != null) 
     { 
      string ExtraErrorData = ""; 

      if (e.Error.Data.Count > 0) 
      { 
       foreach (DictionaryEntry de in e.Error.Data) 
        ExtraErrorData += string.Format(
         " Key: {0,-20}  Value: {1}", 
         "'" + de.Key.ToString() + "'", 
         de.Value) + Environment.NewLine; 
      } 

      Common.LogWindow.Log(string.Format("{0} - Downloading product list - {1}",ShortName, 
       Environment.NewLine + e.Error.Message + 
       Environment.NewLine + ExtraErrorData + 
       Environment.NewLine + e.Result.ToString())); 
       ShopHasErrors = true; 
     } 

     //do rest of finalizing 
    } 

答えて

0

明らかに、私は集中しておらず、テストの間に間違いを犯しています。e.ResultToStringメソッド()の内部の状態をエラー処理でより正確をRunWorkerCompletedとはをRunWorkerCompleted。それは、私が自分のプロジェクトを始めた2014年から、この正確なコードで完璧に働いたという事実を変えるものではありません。削除するe.Result.ToString()コードの問題が解決しました。それがこのように発生し、なぜRunWorkerCompletedコードが答えはミックのポストであるDoWork

+0

によって例外をスロー原因となる理由は、まだ私には謎のまま。彼の答えは、この問題に対する真の解決策です.e.Error!= nullがTargetInvocationExceptionをスローすると、e.Resultにアクセスします。 – almulo

2

の原因となったコードです。

bgwProductListUpdaterRunWorkerCompletedに問題があります.bgwProductListUpdaterDoWork内で例外がスローされたときにTargetInvocationExceptionをスローすることが期待できます。

hereと記載されているように、Error!= nullの場合にResultにアクセスし、CanceledがTrueの場合にInvalidOperationExceptionにアクセスするTargetInvocationExceptionが予想されます。 bgwProductListUpdaterRunWorkerCompleted内のResultプロパティにアクセスする前に、両方をチェックする必要があります。

エラーを処理するときは、例外の処理中にスローされる例外が多大な混乱を招く可能性があるため、注意する必要があります。

関連する問題