Alexprivat schrieb:

VB.NET-Quellcode

1. Catch ex As Exception
2. Return ex.Message
3. End Try

Return ex.Message ist ein NoGo, denn Du merkst nix vom Fehler.
Reich den Fehler einfach durch:
und fang genau diese Exception in Deinem aufrufenden Code ab.

Auf der anderen Seite fliegt nun ganz normal eine Exception die angibt was los ist, es muss nichts zurück gegeben werden.

Wieso auch, man kann nur eine Exception throwen die eine Message beherbergt und nicht die Message an sich.

RodFromGermany schrieb:

Reich den Fehler einfach durch:

VB.NET-Quellcode

1. Catch ex As Exception
2. Throw
3. End Try

Ist das überhaupt notwendig? Catch ex As Exception macht keinen Unterschied welche Exception abgefangen wird, genauso reicht Throw sie einfach durch, insofern könnte man doch den ganzen Try-Catch-Block einfach weglassen (sofern nicht noch andere Catch-Blöcke oder ein Finally-Block darin vorkommen), oder sehe ich das falsch?
Schließlich wird die dann erwartete Exception auch Assembly-übergreifend einfach an den vorherigen Aufrufer durchgereicht, solange bis sie eben ge"catcht" wird.

Korrekt, eigentlich unnötig. - Außer man möchte eigene Exceptions throwen.

Arby schrieb:

reicht Throw sie einfach durch

Ist korrekt, setzt aber (k)ein Fehlerhandling im DLL-Code voraus, dessen Code nicht zur Verfügung stand.

Alexprivat schrieb:

Wie kann ich mir also den "Inhalt" von Throw anzeigen lassen?

Throw reicht die Exception einfach weiter.
In einer DLL ist das, was Du geschrieben hast, nicht sinnvoll, denn wenn die Methode einen String zurück gibt, kannst Du nicht mal so feststellen, dass da ein Fehler aufgetreten ist.
Mach ne MessageBox und behandle den Fehler sinnvoll, z.B. einen Defaultwert zurückgeben.

Alexprivat schrieb:

Die dll gibt keinen String zurück

Alexprivat schrieb:

VB.NET-Quellcode

1. Return ex.Message

Ja was nun?

Alexprivat schrieb:

ich habe eine dll erstellt um eine stored procedure in einer Datenbank auszuführen.

Warum muss man ühaupt eine Dll erstellen, um eine StoredProc aufzurufen?

Anscheinend verstehst du grundlegendes Exception Handling nicht, am besten du liest dich mal im Internet dazu ein.

am besten du liest dich mal im Internet dazu ein.

...und bevor du dir nen Wolf suchst, weil du nicht weißt wo du anfangen sollst und deswegen eigentlich genau hier geladet bist:

Mit Try ... Catch ex As Exception ... End Try fängst du ja eigentlich nur einen Fehler ab, der bei deiner Datenbank-Operation (? - oder was auch immer) auftritt.
Innerhalb des Catch-Blocks hast du nun Zugriff auf dein Exception-Objekt in der Variablen ex, das dir mit der Eigenschaft Message (günstigenfalls) im Klartext sagt, was schiefgelaufen ist.
Da deine Funktion als Rückgabewert den Typ String hat, dachtest du vermutlich es wäre ne tolle Idee, hier im Fehlerfall der Text dieser Fehlermeldung zurückzugeben.

Das Problem ist nur: Woran willst du erkennen, dass im zurückgegebenen String die Fehlermeldung steht und nicht - sagen wir mal - der von deiner Funktion aus der Datenbank abgefragte Wert (oder was auch immer deine Funktion zurückgeben soll)? Du hast sonst keinerlei Unterscheidungskriterium woran du festmachen kannst, ob ein Fehler aufgetreten ist oder nicht. Höchstens wenn du einen als String formatierten Zahlenwert erwartest und eine Fehlermeldung sich aber nicht in einen Integer parsen lässt... na ja.

Also wurde vorgeschlagen, du wirfst einfach eine Exception. In diesem Fall dieselbe Exception, die du schon abgefangen hast. Das macht der einzelne Throw-Befehl ohne Parameter. Alternativ könntest du auch eine eigene Exception erzeugen, die mit - sonst irgendwelchen - Daten füttern und diese dann "throw"en. Wenn du aber einfach nur die Original-Exception durchreichen willst, lässt du halt den Try-Catch-Block in deiner DLL einfach weg. Und hier scheint dir nicht klar zu sein was das bedeutet, hm?

Tritt jetzt in deinem Aufruf von was auch immer in der Datenbank ein Fehler auf, wird eine Exception (Ausnahme) ausgelöst. Das .NET Framework schaut nun rückwärts durch die Aufrufhistorie der verschachtelten Funktionsaufrufe, wo der letzte Try-Catch-Block war, auf den die Exception passt (Catch ex As Exception passt auf alle Ausnahmen). Und dorthin springt er dann komplett zurück - ohne anderen Code, der ggf. dazwischen lag, auszuführen. Fängst du also die Exception in deiner DLL, dann ist hier die Fehlerbehandlung zu Ende, und du musst irgendwie schauen, wie du den Fehlertext (ex.Message) an dein Programm zurück bekommst. Fängst du die Exception aber nicht ab oder wirfst sie einfach neu, dann kehrt die Kontrolle sogar bis zu deinem Programm zurück. Wird sie an dieser Stelle mit Catch gefangen, kannst du hier damit machen, was du machen willst, z.B. ex.Message auslesen und dem Benutzer zur Anzeige bringen.

Wenn du sie allerdings auch in deinem Hauptprogramm nirgends abfängst, landet sie am Ende wieder im Framework, das die allumfassende Kontrolle über dein Programm hat und sorgt nun dafür, dass so eine Meldung kommt wie "Eine Ausnahme ist in Programm an Position xxx aufgetreten" (oder so ähnlich). Und dein Programm wird beendet ("stürzt ab").

Nun klarer?
Verlager also einfach den Try-Catch-Block aus deiner DLL in dein Hauptprogramm wo die DLL-Funktion aufgerufen wird. Dort hast du dann 100%ige Kontrolle ob der von der DLL zurückgemeldete String ein valides Ergebnis ist oder - wenn in den Catch-Block verzweigt wird - ein Fehler aufgetreten ist und gar kein Ergebnis zur Verfügung steht.

Wenn jetzt immer noch was unklar sein sollte, empfehle ich ein gutes Buch über Grundlagen der .NET-Programmierung. @ErfinderDesRades hat da sicher einen oder mehrere Links parat.