Try Catch / throw wird ignoriert

Question

Frohes Neues zusammen!

Ich habe mir für ein Projekt Code für einen zugriff auf einen Webservice generieren lassen. An einer Stelle kann eine ProtocolException auftreten. Diese Exception würde ich gerne, je nach Situation und Programm, anders behandeln lassen.

Dazu kamen mir zwei Möglichkeiten in den Sinn:

1. Ein eigenes Event erzeugen und an anderer Stelle bearbeiten

2. Die ausgelöste Exception weiterreichen

Beides funktioniert nicht. Visual Studio 2013 meldet im Catch-block dass die Exception nicht behandelt wurde. Das folgende Bild würde zeigen, wie die Meldung in Aktion aussieht. (Kann ich leider nicht beifügen wegen der Kontoprüfung) Trotz Try Catch und Throw bleibt die IDE immer hier stehen, und ich komme nicht weiter mit der Entwicklung. Ein lokale Behandlung an dieser Stelle kommt nicht in Frage.

Ich denke, das Problem liegt hier bei der IDE. Leider weiß ich nicht wie ich es beheben kann. Ich hoffe jemand hier hat einen guten Rat :)

Danke und Gruß

André

Answer 1

Hallo,

normalerweise Fängt VS alle Exceptions ab, ohne zu beachten, ob die Ausnahme gefangen wurde oder nicht. 

Wenn der Debugger stoppt, dann hast du normalerweise den Hinweis das eine Ausnahme (erste Chance) geworfen wurde. Du kannst die Fortführung druch "Weiter" erlauben. Im normalen Modus (ohne Debugger) wird der Fehler ganz normal behandelt.

---

© 2015 Thomas Roskop

Answer 2

Hallo Thomas,

danke für die schnelle Meldung. Ich fürchte, das ist nicht ganz das was ich meine. (wollte ja noch das Bild anhängen)

Die IDE bleibt im catch-Block stehen und meldet, dass die Exception nicht behandelt wurde. Das macht sie auch nur dort. An allen anderen Stellen durchläuft sie die Catch-Anweisungen, wenn ein Fehler auftritt, so wie sie es soll.

Answer 3

Hallo André,

zeig doch mal bitte deinen Try Catch Block und poste die genauen Details des Fehlers (bspw. ex.ToString() oder ex.Message inkl. ex.StackTrace, ...)

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 4

Hallo Stefan,

        <System.ComponentModel.EditorBrowsableAttribute(System.ComponentModel.EditorBrowsableState.Advanced)>  _
        Function Webservice_WServicePortType_GetUser(ByVal request As Webservice.GetUserRequest1) As Webservice.GetUserResponse1 Implements Webservice.WServicePortType.GetUser
            Try
                Return MyBase.Channel.GetUser(request)
            Catch ex As System.ServiceModel.ProtocolException
                'MessageBox.Show(ex.Message)                                       
                'Throw New System.ServiceModel.ProtocolException(ex.Message)
                Throw
            End Try
        End Function

Das ist auch schon alles. Die IDE markiert das Throw und schreibt "ProtocolException wurde nicht behandelt". Das macht sie auch, wenn ich die MessageBox benutze, oder eine neue Exception werfe.

Answer 5

Wenn der Debugger stoppt, dann kannst du auch unten bei VS im Fenster Loake Variablen (oder ähnlich...) die Ausnahme sehen und alle Informationen dazu auslesen.

---

© 2015 Thomas Roskop

Answer 6

Korrekt.

Da steht dann halt "Der Remoteserver hat eine unerwartete Antwort zurückgegeben: (405) Method Not Allowed." Deie Ausnahme ist vom Typ ProtocolException.

Kein HelpLink.

Die InnerException sagt "Der Remoteserver hat einen Fehler zurückgegeben: (405) Unzulässige Methode.", was so ziehmlich das Gleiche ist.

Nur helfen die Informationen nicht weiter. Die IDE steht da und sagt "ProtocolException wurde nicht behandelt" obwohl der Catch eben genau diese abfängt.

Ich kann auch einfach Exception abfangen, was an dem Problem nichts ändert.

Answer 7

Hallo André,

in einem Webservice Aufruf sollte man besser eine FaultException-Klasse auslösen statt eine Standard-Exception über ein leeres Throw, damit der Client über den Fehler informiert werden kann. Bei einer normalen Exception wird die Verbindung zwischen Service und Client auch vollständig beendetet und das führt eben zu dem Remoteserver-Fehler.

---

Olaf Helper

[ Blog] [ Xing] [ MVP]

Answer 8

Hallo Olaf,

ich werde versuchen es mir zu merken, danke.

            Try
                Return MyBase.Channel.GetUser(request)
            Catch ex As System.ServiceModel.ProtocolException
                'MessageBox.Show(ex.Message)                                       
                'Throw New System.ServiceModel.ProtocolException(ex.Message)
                Throw New FaultException(ex.Message)
            End Try

Entspricht das dem  wie es sein sollte?

Answer 9

Kleiner Ergänzung:

Die IDE hält jetzt genau da an und schreibt "FaultException wurde nicht behandelt" ... vielleicht weist das auf das Problem hin?!

Answer 10

Hi André,
der Catch-Block reagiert nur auf eine "ProtocolException". Die "FaultException" wird nicht behandelt.

Wie es sein sollte, musst Du erst einmal selbst konzipieren. In jeder Aufrufebene solltest Du festlegen, wie Ausnahmen behandelt werden sollen. Das kann sein:

1. keine Behandlung (kein Try/Catch) und Behandlung in einer übergeordneten Aufrufebene;

2. Behandlung nur bestimmter Typen von Ausnahmen, andere Typen werden in einer übergeordneten Aufrufebene behandelt;

3. abschließende Behandlung, so dass die übergeordnete Aufrufebene keinen Fehler mehr gemeldet bekommt;

4. Weiterleiten einer Fehlermeldung an die übergeordnete Aufrufebene (mittels Throw).

Wenn in keiner der übergeordneten Aufrufebenen ein aufgetretener Fehler abschließend behandelt wird, hält die IDE an oder beim Ausführen des Programmes ohne IDE stürzt es ab (abnormales Ende).

--
Peter

Answer 11

Hallo Peter,

ohne Try Catch bleibt die IDE in der Methode stehen und meldet das Nichtbehandeln der ProtocolException. Deswegen hatte ich bereits an das Throw gedacht. Wie oben beschrieben, bleibt sie aber auch mit try catch und throw einfach an der Stelle stehen.

Die behandlung will ich ja im Aufrufer haben, nur kommt die Meldung da nicht an und ich kann die IDE leider nicht dazu bewegen den Fehler weiterzureichen oder eine neue Exception weiterzureichen.

Answer 12

Ich glaube nicht, dass dies die Schuld der IDE ist. Du gibst ja auch nicht MS-Word die Schuld an Rechtschreibfehlern...

Zu deinen Problem selbst, mir scheint als würde die falsche Ausnahme gefangen werden.

Wenn du eine Ausnahme AException wirfst, kannst du Sie nicht mir BException als Filter fangen.

Also bei solchem Code würde die IDE genau so reagieren (was auch richtig ist)

try {
   //... Code ...
   throw new AException();
} catch(BException bex) { 
   //Dies wird niemals erreicht...
}

Schua dir dochmal an, ob du die richtige Ausnahme fängst und wie VS eingestellt ist (Standarteinstellungen?)

Sollte das nichts bringen versuche doch einfach eine normale Ausnahme (Exception) zu fangen...

---

© 2015 Thomas Roskop

Answer 13

Kleine Änderung:

try catch und im Catchblock nur die MessageBox Funktioniert. hilft aber nicht weiter da ich den fehler dann nur ausgebe und nicht behandel.

Answer 14

Hi Thomas,
schön wäre, wenn Du in der Programmiersprache des Fragestellers bleiben würdest und ihn nicht noch mit sinnlosen Klammern verwirrst.

--
Peter

Answer 15

Hi André,
Du musst auch im Catch-Block auf die Ausnahmen reagieren. Wenn Du das nicht machst und auch keine übergeordnete Aufrufebene auf den Ausnahme-Typ reagiert, bleibt die IDE stehen. Reagiere mal auf alle Ausnahmetypen, z.B. so:

            Try
                Return MyBase.Channel.GetUser(request)
            Catch ex As Exception
' auf alle Ausnahmetypen reagieren.
                MessageBox.Show(ex.Message)                                       
            End Try

--
Peter

Answer 16

@Thomas: hatte deine Nachricht gerade übersehen.

klar muss das nicht die IDE sein. Allerdings habe ich in anderen Programmteilen n-Try catch Blöcke die sich alle so verhalten wie ich es erwarte und verlange. Daher vermute ich einen IDE-Fehler.

@Peter & Thomas:

Wenn der Code so aussieht:

            Try
                Return MyBase.Channel.GetUser(request)
            Catch ex As System.ServiceModel.ProtocolException
                MessageBox.Show(ex.Message)
            End Try

erhalte ich die MessageBox udn das Programm läuft weiter. Würde ich auch erwarten denn -> ProtocolException tritt auf -> Catchblock fängt diese ab

Wird der Code geändert auf:

            Try
                Return MyBase.Channel.GetUser(request)
            Catch ex As System.ServiceModel.ProtocolException
                MessageBox.Show(ex.Message)
                Throw
            End Try

erhalte ich die MessageBox und abschließend bleibt die IDE bei dem Throw stehen und bemängelt die nicht behandelte ProtocolException. Würde also bedeuten: ProtocolException tritt auf -> Catchblock fängt diese ab -> MessageBox wird geöffnet -> ProtocolException gilt (plötzlich??) als nicht behandelt. Oder ist es eine weitere?

Das Throw kann nach belieben auch durch Throw new XyException ersetzt werden.

Das komplette weglassen des Try Catch führt ebenfalls zum Stillstand. (Dann allerdings berechtigt)

Answer 17

Hi André,
mit dem "Throw" erzeugst Du eine neue Ausnahme, die an die übergeordnete Aufrufebene gemeldet wird. Wenn diese neue Ausnahme nicht behandelt wird, bleibt die IDE beim throw stehen.

--
Peter

Answer 18

Mit Throw wird eine neue Ausnahme erstellt (wie Peter bereits schrieb) und diese wandert dann weiter dem Aufrufstack entlang, muss also übergeordnet gefangen werden.

Du kannst aber den Fehler weiterleiten, wenn du die Ausnahme mit "Throw ex" weiterleitest, oder eine neue Ausnahme erstellen, und die aktuelle Ausnahme als Argument mit übergeben.

Und Entschuldigung Peter, hast recht, ich habe leider die falsche Sprache verwendet :-(

---

© 2015 Thomas Roskop

Answer 19

Hallo Peter,

danke, genau da liegt mein Gedankefehler. Ich habe das Throw so verstanden, dass der Fehler unbehandelt weitergegeben werden soll / kann. Dass das Throw ein komplett neue Exception erzeugt, wusste ich nicht. Wobei ich auch dann nicht erwarten würde, dass direkt am Throw die Behandlung beanstanded wird.

Von der IDE habe ich daher erwartet den Fehler im Aufrufer als nicht behandelt anzuzeigen.

Wenn ich also in der Methode keine Behandlung vornehme, im Aufrufer den try catch verwende, funktioniert es so wie ich es mit dem throw erwartet hätte.

... werde mir das Throw Konzept wohl noch ein paar mal durch den Kopf gehen lassen müssen.

Danke auch an alle Anderen, das war sehr hilfreich!