Laden...

Parallel.For (TPL) Exception innerhalb einens threads wird nicht als AggregateException weitergeleit

Erstellt von tonka vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.018 Views
tonka Themenstarter:in
373 Beiträge seit 2006
vor 13 Jahren
Parallel.For (TPL) Exception innerhalb einens threads wird nicht als AggregateException weitergeleit

Hy@all,

ich habe gerade testhalber eine Exception innerhalb einer Parallel.For geworfen, um wie in den Doku's beschriebenen AggregatException zu testen. Jedoch kann ich die Exception nicht (ab)fangen => Wieso?

Hier ist der TestCode:


try
                {
                    Parallel.For<Info>(0, CountOf, () => new Info(), (k, loop, localstate) =>
                    {                        
                            throw new Exception("Test-Error");
                        return localstate;
                    },
                        (localstate) => { lock (localobj) { globalInfo += localstate; } }
                    );
                }
                catch (AggregateException ex)
                {
                    string a = "";
                }
                catch (Exception ex)
                {
                    string b = "";
                }

Im Codebeispiel von MS stehts auch so

MfG
Tonka

6.862 Beiträge seit 2003
vor 13 Jahren

Hallo,

doch, der Code solllte tun. Hab den mal in ne Konsolenanwendung getan und wie erwartet kommt die AggregateException.

Baka wa shinanakya naoranai.

Mein XING Profil.

849 Beiträge seit 2006
vor 13 Jahren

Demhab ich auch so getan, die Exception wird geworfen.. CountOf ist nicht zufällig 0?

tonka Themenstarter:in
373 Beiträge seit 2006
vor 13 Jahren

Hallo,

CountOf ist nicht 0! Kann das eventuell daran liegen, das die Parallel.For nocht in einem eiegenen Task steckt (non-gui)?

Habe kurz ein Test-Consolen-Programm geschrieben, dort habe ich den gleichen Effekt!

6.911 Beiträge seit 2009
vor 13 Jahren

Hallo,

wenn die Parallel.For-Schleife im GUI-Thread aufgerufen wird dann blockiert sie diesen solange bis die Schleife fertig ist. Also bei GUI die Parallel.For in einem Task.StartNew aufrufen.

Setzt mal einen Breakpoint beim throw und schau was passiert.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

tonka Themenstarter:in
373 Beiträge seit 2006
vor 13 Jahren

wenn die Parallel.For-Schleife im GUI-Thread aufgerufen wird dann blockiert sie diesen solange bis die Schleife fertig ist. Also bei GUI die Parallel.For in einem Task.StartNew aufrufen.

Genau das habe ich ja.

tonka Themenstarter:in
373 Beiträge seit 2006
vor 13 Jahren

Habe kurz ein Testconsole-App geschrieben.


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace ParallelTest2
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                Int32 GlobalState = 0;
                Object locker = new Object();
                const Int32 CountOf = 100000;
                Parallel.For<Int32>(0, CountOf, () => 0, (k, loop, localstate) =>
                    {
                        throw new Exception("Error-Test");
                        return localstate;
                    },
                    (localstate) => { lock (locker) { GlobalState += localstate; } }
                );
            }
            catch (AggregateException ex)
            {
                string a = "";//<- hier komme ich nicht
            }
        
        }
    }
}

Der Effekt bleibt!

6.862 Beiträge seit 2003
vor 13 Jahren

Hallo,

die App tut problemlos. Ein Breakpoint an deiner makierten Stelle und er springt problemlos rein.

Baka wa shinanakya naoranai.

Mein XING Profil.

tonka Themenstarter:in
373 Beiträge seit 2006
vor 13 Jahren

komisch, habs gerade bei meinem Kollegen ausprobiert, der hat das selbe Problem wie ich. Gibt es irgendwelche Einstellungen die man in VS ändern muss?

6.862 Beiträge seit 2003
vor 13 Jahren

Hallo,

Man kann einstellen bei was für behandelten und unbehandelten Exceptions VS automatisch anhalten soll. Aber das bringt hier nichts. Wenn man einen Breakpoint im Exceptionhandler setzt muss er auf jeden Fall dort anhalten, da der Code ja ausgeführt wird. Ersetz testweise mal deine Zuweisung an den String mit der Ausgabe auf der Console und lass das Programm mal ohne Debugger laufen - kommt dann die Ausgabe?

Baka wa shinanakya naoranai.

Mein XING Profil.

297 Beiträge seit 2008
vor 13 Jahren

Eventuell bist du nur irritiert, weil VS zuerst meldet, dass die Exception nicht behandelt wurde und an dieser Stelle anhält. Wenn du das Programm dann aber weiterlaufen lässt, kommt er auch irgendwann zum Catch-Block.

There are 10 kind of people, those who understand binary and those who don't.

tonka Themenstarter:in
373 Beiträge seit 2006
vor 13 Jahren

@Talla: Hba jetzt den Breakpoint auf "throw ex" gesetzt => das system geht dann zu den exceptions weiter. Wenn ich ohne Debugger starte wird die Exception nicht dargestellt und catch ganz normal aufgerufen.

@Schlopp: Ja, das irritiert mich 😉

Das heißt, das ich ein "normalen" Ablauf nur ohne Debugger erreiche, mit Debugger muss ich die Exception mit "F5" weiterdrücken => Stimmt das?

6.862 Beiträge seit 2003
vor 13 Jahren

Hallo,

mit dem Breakpoint beim throw wirst du nicht weit kommen da du wenn du z.B. schrittweise weitergehts niemals zum catch kommst, weil das in nem anderen Thread läuft. Mach einfach mal nur nen Breakpoint im Exceptionhandler, dann wirst du auch sehen das du dort landest und die Exception korrekt geworfen und gefangen wurde.

Baka wa shinanakya naoranai.

Mein XING Profil.

297 Beiträge seit 2008
vor 13 Jahren

@tonka: Genau, einfach die Exception mit F5 weiterdrücken, dann kommst du irgendwann in den AggregateException-Catch-Block.

There are 10 kind of people, those who understand binary and those who don't.

tonka Themenstarter:in
373 Beiträge seit 2006
vor 13 Jahren

Danke für eure Hilfe!